Steve Spano wrote:
Hi John,
Thanks for the reply.
I did more tracking into this, the mad_decoder_buffer creates the instances on the frame/stream/sync data. I already created two instances of the mad_decoder_buffer so I could link them to each RTOS thread.
It looks like the samples are getting mixed up at the output stage. It turns out that one of the MP3s playing is a 1-channel and the other MP3 is a 2-channel. Any thoughts perhaps on how mixing of sample data, between RTOS tasks, could occur on the output stages?
You'll need to make output the data rates agree potentially converting one to the other. And you will need to synchronize and mix the two streams before they hit the audio device. This should be relatively straightforward but you may need to scale the data to avoid clipping during the mix operation.
-john
I figured this part out, that it is occurring at the output stage, Friday ~ 5pm. I have to look at it some more.
Thanks
Steve Spano, President Finger Lakes Engineering
-----Original Message----- From: john cooper [mailto:john.cooper@third-harmonic.com] Sent: Friday, December 07, 2007 10:09 AM To: Steve Spano Cc: mad-user@lists.mars.org; john cooper Subject: Re: [mad-user] dual-thread libmad
Steve Spano wrote:
I have a simple RTOS which has two threads. Each thread starts lib mad
with a dedicated mad_decoder buffer for each thread. I am now able to "read" data correcting into the decoders (i.e. I don't see decoding errors streaming everywhere on the debug trace) but the output audio
is
mixed up. Meaning that the audio from the two threads is being mixed (actually shuffled) during playback.
It is built into the API. You'll need to keep separate frame/stream/synth data structures for each instance of a decode operation. Sounds like you are rendering to the same set of structures multiplexed by the task scheduler.
-john