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

[Joakim Plate]

Hi

> 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.. 

/Joakim