[pulseaudio-discuss] Monitoring and Pulseaudio accuracy

[Colin Guthrie]

'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
> something?

ne = network endian IIUC which is always big endian...

http://en.wikipedia.org/wiki/Endianness#Endianness_in_networking

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
   Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
   Mandriva Linux Contributor [http://www.mandriva.com/]
   PulseAudio Hacker [http://www.pulseaudio.org/]
   Trac Hacker [http://trac.edgewall.org/]