[pulseaudio-discuss] [RFC - MP3 passthrough over A2DP 1/2] mp3 passthrough: core changes
bossart.nospam at gmail.com
Wed Sep 22 21:20:41 PDT 2010
> Annoyingly, no I don't have list rights... I asked a while ago, but no
> reply :(
Oh well, I will rework the patch and repost it in a couple of days...
> It was my understanding that Lennart wanted to have some way to extract
> timeing infromation from compressed codecs etc. to allow for wakeup
> times to be calculated properly. I'm not sure if the usec conversions
> need some kind of supplement for compressed formats? I suspect however
> if timing information is to be extracted successfully from these
> formats, we'd need to know which format it actually is.
> Your suggestion seems reasonable, but not sure it can be used without
> API breakage (e.g. the extra subtype information?). I've not really
> looked to closely so this may not be an issue at all.
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.
In terms of API changes, for the passthrough work I managed to avoid
any breakage with an additional flag. I think if we change the
pa_sample_t and add new fields, we will break everything. Maybe we can
change the API in a backwards compatible mode, where we use a
pa_sample_extended_t if this flag is set. The native protocol would
need to change no matter what, but if this is hidden in libpulse we
should be good, right?
More information about the pulseaudio-discuss