breez said:
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/showthread.php?postid=1593456#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.
phofman said:
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.
SoX 14.1.0
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
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 said:
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/viewvc/sox/sox/src/rate.c?r1=1.31&r2=1.32
BTW, the CVS version has new parameters http://sox.cvs.sourceforge.net/viewvc/sox/sox/src/rate.c?view=markup . Looks pretty good now.
.: ZMN :. said:
I have not tested the glitchfree version, nevertheless have followed the discussion of pulseaudio's author Lennart on alsa-devel mailing list. I think the glitchfree feature brings ability to fine-tune latency for each application separately as some require low latency while other enjoy the benefit of large buffers and lower CPU overhead.
In any case great kudos to Lennart for his incredible effort in bringing modern features to linux AND his relentless push for alsa API cleanup which is so desperately needed and apparently not easy to accomplish.
ackcheng said:
I think I have mentioned this previously.
Puppy linux does this and is only 90mb in total. SPB linux doesn't really provide as flexible a platform, and the community of puppy linux is similar to that of ubuntu. Packages from the slackware repositories can be installed on puppy and it is only a few kernel revisions behind the bleeding edge - it is as flexible as a mini OS gets. It can easily run off a small cf disk in an ide adapter to eliminate internal hard drive noise. This is what I have at the moment with a fanless CPU and PSU. There is a guide to setting up a headless mpd / puppy linux machine at diy paradise.
I have tried puppy with low latency patches but it broke quite a few useful features. But I am happy with the performance without these.
I think it is the squashfs filesystem kernel patches used in these mini distros that allows them to run from ram. I would imagine that ubuntu studio is far too big to be run from ram on the average machine. However, an ubuntu server patched for low latency running mpd and brutefir and controled remotely could boot off a small flash drive and run comfortably in ram to avoid excess read/write of the flash media.
phofman said:
Indeed! Massive kudos to Lennart and all others involved in improving the sound system on Linux.
Are you aware of any distribution that will incorporate the glitchfree part in their next upgrade/update? I use Ubuntu and from what I have read, the updated pulseaudio and the required ALSA API updates will not make it in to the next big upgrade (due this month).
phofman said:
rossco_50 said:
Meawhile I wonder why one should run the entire system from ram!?!
I just made mpd - one particular playlist-folder to be exact- run of shared memory by a start script.
A kind of hack but if works:
#!/bin/bash
#
# witten by soundcheck rev 0.1 09-16-2008
#
# This mpd script sets up mpd to play files from shared memory on the mpd-server
# There won't be any disc access while playing the selected directory back
# You need to prepare the environment first:
# 1. edit /etc/mpd.conf: All config files db_file/log_file/error_file/pid_file/state_file configs should point to /dev/shm/.mpd/xxxxxx
# 2. Install mpc: sudo apt-get install mpc
# 3. cp ~/.mpd/state ~/.mpd/state.default Note: If the file state is not empty run $mpc clear to generate a default state file.
# 4. cd <your_musicdir> && ln -s /dev/shm AAA
# 5. mv /usr/bin/mpd /usr/bin/mpd.bin
# 6. save this -script-file under /usr/bin/mpd as root (sudo) and $chmod 777 /usr/bin/mpd
#
# Start:
# mpd <your-album-dir>
# Now you'll find a playlist of you shared memory under folder AAA in e.g. Minion
#
# Note: You'll loose the state file and its content as soon as you restart mpd.
MUSICDIR=/home/klaus/music
case "$1" in
"") echo "----------------------------------------------"
echo "Please specify album-directory - run-command: mpd <album-dir-without-slashes and-path>"
echo "----------------------------------------------"
exit 1
;;
esac
[ ! -d "${1}" ] && echo -e "Cant' find specified album-directory. Please check name!" && exit 1
mpc stop
rm /dev/shm/*wav > /dev/null 2>&1
echo "Copy data to Ram!"
cp $1/*wav /dev/shm
cp /home/klaus/.mpd/state.default /home/klaus/.mpd/state
cp -rf /home/klaus/.mpd /dev/shm/.mpd
killall mpd.bin
chrt -f -p 10 /usr/bin/mpd.bin /etc/mpd.conf # this option works on real time kernels.
mpc update AAA
mpc ls | grep AAA | mpc add
exit 0
###End of Script
anbello said:
Andrea.
Because it is just another layer in between. I assume many of the users will only play stereo data from one source via mpd towards brutefir via Alsa to mutiple outs. I think jack would be overkill in this application.
What would be the benefit to have Jack in there?
Cheers
Klaus
soundcheck said:
I agree. No benefit for ubuntu on a higher spec machine, especially where there is no disc activity during playback.
But through puppy I have a very affordable and efficient system with no moving parts (except external usb drive) which I believe sounds good. It has more overhead than it would running ubuntu. I will be interested to see if mpd and the emu alsa drivers will ever support 24bit - my hardware may then be the limiting factor for high res files.
soundcheck said:
Yes it's another layer but with no negative effect for what i know and for what i hear in my sytem (MPD, brutefir with DRC fliter, jack, alsa, terratech aureon 7.1 space with envy24 chipset and wolfson dac).
Moreover it adds flexibilty to the system and it's very easy to use to connect application to each other and to sources and sinks.
ciao
andrea
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.