[pulseaudio-discuss] [RFC - MP3 passthrough over A2DP 1/2] mp3 passthrough: core changes
Colin Guthrie
gmane at colin.guthr.ie
Wed Sep 22 06:28:43 PDT 2010
'Twas brillig, and pl bossart at 22/09/10 14:10 did gyre and gimble:
>>> 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?
Annoyingly, no I don't have list rights... I asked a while ago, but no
reply :(
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 :)
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/]
More information about the pulseaudio-discuss
mailing list