Re: mad-dev digest, Vol 1 #368 - 2 msgs

> I'm planning to use MAD in a streaming application.  I have no
> control over
> the incoming data rate, although it is ostensibly CBR data with a
> fixed
> sample rate.  Similarly, the processing rate of the decoded samples is
> controlled by the DAC.  So inevitably sooner or later I'll get a
> buffer
> overflow or underflow.

So if I understand, the input can be for instance 128kbps or 160kbps, but
the DAC expects a fixed rate of PCM samples? I don't see a problem then,
since the rate of PCM samples is independent on the bitrate of the
MPEG-stream. So your PCM-samples will be delivered to the DAC with always
the same speed.



The problem can occur, if the data has also an unknown samplerate (32kHz or
44,1kHz for instance).



I had this problem with a network-streaming-device. The MPEG input could and
would vary from time to time and this would happen completely randomly. As
long as you have some buffering in front of MAD, the decoder has no problem
in handling this since it will decode CBR frame by frame.



Handling sample-rate changes is more difficult. I added also a small amount
of double buffering after the MAD library and I added a small check after
the MAD decoder, to see whether the samplerate changed compared to the
previous sample. (And for instance 'stereoness' - although that is easy to
handle: simply copy the channel to L+R).



If a samplerate change was detected, it would switch buffers at once to have
the decoded frames with the new samplerate go into the second buffer, while
the DAC was still fed from the first. When the first buffer was emptied
under a certain level, I would activate a samplerate conversion function on
the second buffer. When the first buffer was then empty, the DAC would be
fed from that moment on with the converted second buffer, and new decoded
samples would enter the first buffer and the process would repeat itself
until that buffer was full or another sample-rate conversion was detected.



Regards,



Armin