I am trying to use sox to increase the amplitude of audio stream in an
mjpeg file, but before doing so, i am using sox's "stat" to determine
the max. amplitude without clippping.
So my command line is:
$ lav2wav file.eli | sox -t wav - -t wav /dev/null stat -v
but both lav2wav and sox both use u
Hi Brian,
On Mon, 21 Jun 2004, Brian J. Murrell wrote:
> $ lav2wav file.eli | sox -t wav - -t wav /dev/null stat -v
> but both lav2wav and sox both use up negligible CPU in doing this job
I think people (in the past) have said that adding 'buffer' in the middle
could significantly improve this. I
On Mon, Jun 21, 2004 at 09:42:52AM -0400, Brian J. Murrell wrote:
> ...
> So my command line is:
>
> $ lav2wav file.eli | sox -t wav - -t wav /dev/null stat -v
>
> but both lav2wav and sox both use up negligible CPU in doing this
> job, and it takes far too long. lav2wav's CPU usage is about 2%
On Mon, 2004-06-21 at 10:28 -0400, Richard Ellis wrote:
> Check your disk I/O read bandwidth. Lav2wav is heavily read I/O
> bandwidth bound. It sounds like your disk read bandwidth is way low
> for some reason,
That was one of the first things I checked. This is a UDMA5 capable
drive although
On Mon, Jun 21, 2004 at 11:11:09AM -0400, Brian J. Murrell wrote:
> On Mon, 2004-06-21 at 10:28 -0400, Richard Ellis wrote:
>
> > Check your disk I/O read bandwidth. Lav2wav is heavily read I/O
> > bandwidth bound. ...
>
> /dev/hda:
> Timing buffer-cache reads: 636 MB in 2.00 seconds = 318.0
On Mon, 2004-06-21 at 11:26 -0400, Richard Ellis wrote:
>
> That should be more than enough, as long as you've not got something
> in the background consuming 40.06MB/sec of read bandwidth, or
> something else writing loads of data to disk at the same time.
Right.
> Your original command line wa
On Mon, Jun 21, 2004 at 03:25:54PM -0400, Brian J. Murrell wrote:
> Right but since then I have simplified the test to just lav2wav sucking.
> See my previous e-mail:
>
> $ time lav2wav file.eli > file.wav
>INFO: [lav2wav] WAV done
> 0.58user 12.01system 1:49.86elapsed
