'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/]
