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

[Colin Guthrie]

'Twas brillig, and pl bossart at 23/09/10 05:20 did gyre and gimble:
>> 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.

Cool, that all sounds good to me :)

I wonder if it was just the compression scheme to be used for tunnel
sinks that had a timing-information-sans-full-decode requirement (or
desire)... I remember it was discussed in the past but probably applying
that principle in the wrong place :D

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

Yeah native protocol can change quite happily. This is hidden by
libpulse like you say.

Cheers

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]