Subject: Re: [ecasound] New double-buffering: report after a quick try
From: Jeremy Hall (jhall@uu.net)
Date: Sat Dec 02 2000 - 21:00:04 EET
I was playing an mp3 file and noticed the following:
Because I had grafted onto an already encoding stream of mp3 data, there
was some junk at the beginning of the file. The packets are multicasted
in 1k blocks, so I zeroed the first couple blocks so that mpg123 would
correctly determine the bitrate. In the end, I had to decode the data,
then recode the data again so that the frames would line up
properly. Even though ecasound was playing the mp3 file correctly, when
told to fw 150 (like to forward through commercials) ecasound would jump
WAY beyond this and land somewhere in the NEXT commercial
break. Obviously this resulted in a signifficant amount of confusion.
After recoding the file, ecasound ehaved normally with the following
exceptions.
Occasionally, ecasound would stop, requiring a t command to help it
resume. This might have been an artifact of the file growing, who
knows. When this happened, I found it necessary to stop, rewind a few
seconds, cs-connect, then start again. Any other actions either resulted
in the mpg123 playing minutes after being told to stop from ecasound or
ecasound coredumping.
I would prefer not to have to recode an mp3 stream just to make ecasound
work correctly. At one point, I even managed to get the output of mpg123
to appear on stdout. This was MOST undesirable, as mpg123 produces quite
a LOT of output.
_J
In the new year, Kai Vehmanen wrote:
> Ok, updated the CVS-tree again. Quite a few small changes (see NEWS for
> the up-to-date list). But the main thing is of course -z:db ...
>
> On Tue, 21 Nov 2000, Kai Vehmanen wrote:
>
> >> command) all output was frozen: that is although I could type commands
> > 'reset' command (from the ncurses package) is your friend here.
>
> I've now removed most debug messages. You can get some of them back using
> -d param.
>
> >> position (with the fs command) showed me that ecasound really thought
> >> that it was arrived at the end of the file. I did all my testing using
> > Hmm, yes, at the moment end-of-file occurs about 1-2secs too early because
>
> This should be now fixed.
>
> > True. At the moment, size of the double-buffer is hard-coded to 64 *
> > buffersize. So if you lower the buffersize much beyond 1024 (which I
>
> This has changed. You can now specify a default size in ~/.ecasoundrc. On
> the command-line you can override the default by issuing something like
> '-z:db,200000'. Buffersize in in sample frames (defaults to 100000).
>
> >> move around in the files, such as fw, rw and setpos, yielded VERY
> >> strange results, not the ones expected at any rate.
>
> These are still broken. I need to come up with a clean solution.
>
> Also, -z:db now behaves fine under SCHED_FIFO priority (-r).
>
> --
> . http://www.eca.cx ... [ audio software for linux ] /\ .
> . http://www.eca.cx/aivastus ... [ aivastus net radio ] /\ .
> . http://www.eca.cx/sculpscape [ my armchair-tunes mp3/ra/wav ]
>
> --
> To unsubscribe send message 'unsubscribe' in the body of the
> message to <ecasound-list-request@wakkanet.fi>.
>
-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request@wakkanet.fi>.
This archive was generated by hypermail 2b28 : Sat Dec 02 2000 - 21:32:19 EET