[pulseaudio-discuss] [RFC - MP3 passthrough over A2DP 1/2] mp3 passthrough: core changes

[pl bossart]

>> There's no real way you can extract timing information just by looking
>> at the data. You either need to parse the frames (what I did for the
>> BT work) or  let the hardware report the number of samples it decoded
>> and rendered. In both cases, you could find out what the average bit
>> rate is and have an approximate idea of the relationship between the
>> numbers of bytes passed to pulseaudio and the duration. It would be a
>> bad idea though to rely on this approximated bitrate to infer timing.
>> The client should get the audio time as reported by this sample count,
>> not through inversion of an approximation that will only be correct
>> for constant bit rates. Instead of basing all time ports on
>> GET_LATENCY messages we should really have a new GET_TIME message.
>
> Why can't the encoded data for MP3 be handled the same way as DTS/AC3 over
> spdif/hdmi? They are preformatted with a iec958 header and padded with zeroes to
> the correct sample length given samplerate and channel count.
>
> To padding and adding of this header is up to the application. Now if a2dp
> supports mp3 as a raw format can't the a2dp code in bluez or whatever is
> communicating with the a2dp device strip the header.
>
> This way timing through pulse remains simple..

That's exactly my plan. I experimented with raw frames and it turned
out to require too many changes. So yes the Mp3 stream would be
reformatted as an IEC61937 format, and the pulseaudio sink would
indeed strip the additional header and padding.
The issue is that you can have different IEC61937 formats, and I would
like to have additional information passed rather than the existing
'passthrough' flag. This is mainly need to make sure you link a
sink_input with a sink that supports the relevant format.
-Pierre