> 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? Cheers, -Pierre
