Linux Audio the way to go!?

[soundcheck]

An idea just crossed my mind:

MPD output to stdout feeding brutefir daemon on stdin.

Anybody tried this?

[breez]

How would I get a linux box take S/PDIF input, decode AC3/DTS or plain PCM and feed this to brutefir? Names of software, general description of the system etc. would be helpful, I can figure out the small details.

[phofman]

Originally posted by breez
How would I get a linux box take S/PDIF input, decode AC3/DTS or plain PCM and feed this to brutefir? Names of software, general description of the system etc. would be helpful, I can figure out the small details.

Conversion from AC3/DTS should be provided by ffmpeg (I have not tested myself, but it is definitely feasible as all linux players can decode 5.1 AC3/DTS and are mostly based on ffmpeg). Once in multichannel wav, you can pipe it to jack and proceed in a regular way.

BUT the playback chain is clocked by output soundcard clock. If your incoming SPDIF stream is not synchronized with the output soundcard clock, you will eventually encounter buffer underruns/overruns (see http://www.diyaudio.com/forums/showt...56#post1593456 and later). You could use only one sound card for input and output, or you could clock the output card via SPDIF output of the input card (if they support such arrangement). In both cases you would get identical input and output sample rate, no room for upsampling in the PC (unless your card chip allowed doubling the output sample rate from the input SPDIF rate which is possible by hacking the alsa driver for some ICE1724-based cards).


Plus if you intend to use the setup for AV, expect a pretty long sound latency which your video chain must be able to compensate for (I do not think regular DVD players offer so large video delays).

Playing directly from PC would be MUCH easier.

In any way it is a rather complicated setup which would require some knowledge of linux audio.

[breez]

Originally posted by phofman


Conversion from AC3/DTS should be provided by ffmpeg (I have not tested myself, but it is definitely feasible as all linux players can decode 5.1 AC3/DTS and are mostly based on ffmpeg). Once in multichannel wav, you can pipe it to jack and proceed in a regular way.

BUT the playback chain is clocked by output soundcard clock. If your incoming SPDIF stream is not synchronized with the output soundcard clock, you will eventually encounter buffer underruns/overruns (see http://www.diyaudio.com/forums/showt...56#post1593456 and later). You could use only one sound card for input and output, or you could clock the output card via SPDIF output of the input card (if they support such arrangement). In both cases you would get identical input and output sample rate, no room for upsampling in the PC (unless your card chip allowed doubling the output sample rate from the input SPDIF rate which is possible by hacking the alsa driver for some ICE1724-based cards).


Plus if you intend to use the setup for AV, expect a pretty long sound latency which your video chain must be able to compensate for (I do not think regular DVD players offer so large video delays).

Playing directly from PC would be MUCH easier.

In any way it is a rather complicated setup which would require some knowledge of linux audio.

Thanks for the reply!

I can synchronize the S/PDIF output to the input (the output hardware allows internal/external sync). Both devices are PCs, video delay ok.

This is really just an afterthought to an already implemented DRC/crossover standalone box and I have a few channels left for surround sound! I'm no AV enthusiast, but rear channels for the occasional movie or multi channel record would be nice.

I'll look into ffmpeg and jack and see how piping streams works.

[phofman]

If it is PC to PC, did you consider linking somehow via ethernet instead of SPDIF? Using a suitable protocol (e.g. netjack) you could avoid the synchronization issue. Unless the playback machine is running windows, very limited options for that inflexible OS.

[ronybc]

Hello all... coming back to this thread after an entire year...!

well.. with a good news... i just got hit by the latest SoX 14.1.0, introducing a far more better resampling effect.. 'rate'. The 'resample', 'polyphase' and 'rabbit' effects are now deprecated.

see the comparison at: http://www.ronybc.8k.com/linux-tweaks.htm#sox

[soundcheck]

Hi Rony.

What "rabbit" version (libsamplerate?) and mode (best sinc?) had been used?

\Klaus

[.: ZMN :.]

Out of curiosity...

Has anyone tried the latest pulseaudio (>= 0.9.11) with its "glitchfree" feature? It has not shown up stable in the distribution I use and it is supposed to be a big improvement in audio time scheduling.

Matth.

[anbello]

Originally posted by soundcheck
An idea just crossed my mind:

MPD output to stdout feeding brutefir daemon on stdin.

Anybody tried this?

Sorry, maybe i missed something but why don't use jackd as glue between MPD and brutefir?

ciao
andrea

[phofman]

Originally posted by soundcheck
Hi Rony.

What "rabbit" version (libsamplerate?) and mode (best sinc?) had been used?

\Klaus

I peeked at the code of the new version, it is using principles outlined in http://ldesoras.free.fr/doc/articles/resampler-en.pdf. Revision 1.32 brought the new functionality http://sox.cvs.sourceforge.net/viewv...1=1.31&r2=1.32

BTW, the CVS version has new parameters http://sox.cvs.sourceforge.net/viewv....c?view=markup . Looks pretty good now.