Subject: Re: [ecasound] New double-buffering: report after a quick try
From: Kai Vehmanen (firstname.lastname@example.org)
Date: Thu Dec 07 2000 - 00:52:00 EET
On Sat, 2 Dec 2000, Jeremy Hall wrote:
> 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
Uh, mp3 input has never worked perfectly. During the last few months, I've
made some random fixes, but many times these fixes have introduced new
bugs. The current CVS code (check your ~/.ecasoundrc to see whether you
have --stereo and -r passed as mpg123 params; if not, delete the line and
ecasound will reset to the new default) should work nicely as it
ignores most of the mp3-header parsing code in layer.cpp.
> 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.
Only way for ecasound to know whether an mp3 input stream has ended, is to
check whether we got exactly as many bytes as we requested for. Now if for
some reasonm, in the middle of the stream we get less bytes (than
buffersize), the mp3 input object will change its state to finished. If we
ignore this, commands like "ecasound -i file.mp3 -o null" will never exit.
-- . http://www.eca.cx ... [ audio software for linux ] /\ . . http://www.eca.cx/aivastus ... [ aivastus net radio ] /\ .
-- To unsubscribe send message 'unsubscribe' in the body of the message to <email@example.com>.
This archive was generated by hypermail 2b28 : Thu Dec 07 2000 - 01:12:17 EET