Pierre-Louis Bossart <pierre-louis.bossart <at> linux.intel.com> writes: > > On 9/5/14, 10:15 AM, CS wrote: > > I understand that passthrough mode is implemented to handle scenarios > > where hardware based decoders are ported, so that PA daemon don't apply > > resampling etc. But I don't see any compressed API calls from PA. How this > > can be achieved? > > The passthrough mode is not directly linked to the ALSA compressed API. > This mode relies on a packetization of the compressed data in an > IEC-like format (padded with header and zeroes) for pulseaudio to handle > timing correctly. The sink is where the compressed data is processed. > You can either send the IEC-like data straight to the receiver (e.g. > with Dolby/DTS payload), or you can extract the data and repacketize it > (MP3 for A2DP passthrough), and last you strip the header and pass the > payload to your hardware decoder using the compressed API. These choices > are part of the sink implementation, PulseAudio will use the data in a > generic manner all the way to the sink. > Does this answer to the question? > -Pierre > First of all, Thanks a lot Pierre for your reply. My reply and further question are added inline below. Please clarify. > This mode relies on a packetization of the compressed data in an > IEC-like format (padded with header and zeroes) for pulseaudio to handle > timing correctly. Who is doing the packetization? Do you mean pulse audio does packetization? If so where this is done? Can we avoid packetization completely so that MP3 data can be sent directly to sink. > and last you strip the header and pass the > payload to your hardware decoder using the compressed API. Do you mean by stripping the IEC header frame with MP3 header will be there and pass the same to hardware decoder? Regd compressed API, do you mean we need to implement a new module like module-alsa-sink which handles compressed alsa calls.
