[pulseaudio-discuss] Monitoring and Pulseaudio accuracy
gmane at colin.guthr.ie
Mon Nov 30 03:22:49 PST 2009
'Twas brillig, and Neil Wilson at 30/11/09 10:33 did gyre and gimble:
> That got me thinking. Can pulseaudio maintain a 'clean path'
> throughout the entire software chain?
Not yet. The intention is to add passthrough support to ensure that we
do not decode+reencode unless needed. This will allow e.g. AC3 audio to
be passed through to the hardware that supports it. The problem here is
that this will only work when not doing mixing and (probably more
problematic) extracting timing information from encoded streams.
> I'm presuming that some sort of rounding or conversion internally has
> altered the float32le. Is there a representation that would be more
> likely to come through 'clean'?
I'm not 100% sure here. Other people may have better knowledge of this
area then me.
> Additionally when I was doing a parec on the Monitor and used the
> 'float32ne' format it seemed to come out Big Endian on an Intel
> machine, which surprised me a little. Is that a bug or did I miss
ne = network endian IIUC which is always big endian...
Tribalogic Limited [http://www.tribalogic.net/]
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
More information about the pulseaudio-discuss