>> Again, unless there's a good reason not to, I'd put >> pa_assert(spec->format != PA_MP3) here. > > If the plan is to add other codec support longer term, then perhaps a > function is better? > > e.g. > > pa_assert(!pa_format_is_compressed(spec->format)); > > That way others can be added more easily in the future? > (not sure if this is a concern or if PA_MP3 would be better named as > PA_ENCODED_DATA, but my guess is that some kind of timing information > will eventually be extracted from MP3 streams to control processor wake > up/sleep times etc, and thus individual encoding systems would have to > be identified separately as is currently with PA_MP3)
That was one of the points I listed. If we start adding support for AC3, DTS, MP3, AAC, we will never cease updating these files. I would be better to signal that the format is ENCODED, meaning all the bytes to usec conversions used for PCM do not apply, and have a second structure that would list the type and possibly contain some parameters required by the decoder. It looks like my main patch was not published since it's slightly over the size limit. I did make a lot of changes in the module-bluetooth-device code, not sure how I can break those in pieces. Does anyone have admin rights to let it through? Thanks. -Pierre _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss