|PC Based Computer music servers, crossovers, and equalization|
Please consider donating to help us continue to serve you.
Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
||Thread Tools||Search this Thread|
|6th January 2007, 05:42 PM||#21|
I just played a bit with the ALSA-buffers to check how well my realtime kernel performs.
I managed to get down to 4us (default 500us) buffer and 1us periodsize. "Lower" values gave me xruns.
I changed the values manually in ~/.xmms. The application won't allow setting up these low values.
I don't know if there are more buffers in the chain (application-alsa-sounddriver-device)?
I am adressing my USB-DAC straight (hd:1,0) away, without going through a mixer (dmix) to avoid any sound manipulation or delay.
4us would equals a fifth of a 48kHz sample, right!?.
Afaik my PCM2707 receiver buffers three stereo samples = 60us.
Do I make a mistake here? I'd call that pretty much "Realtime" unless somebody else tells me that I can't look at it like that.
I can pass on the stream almost transparent from source (xmms) to the DAC.
What I don't get here, is that I can configure 4us and it still
works. Not even one period is needed to be buffered.
Would be great if somebody (even on non-RT systems) could try this little exercise on his system to see how it performs when lowering the ALSA buffers.
Gives us some kind of benchmark!
I am still trying to figure out, which IRQs are causing the XRUNS.
I just got my interrupt-table improved (one interrupt per device),
by disabling devices which are not needed.
Before that I had certain devices sitting on the same interrupt.
(I'll test this tonight)
I am trying now to figure out, how to change PCI-latencies (setpci) to give the soundcard device highest priority.
Somehow the devices are not changable, even though the command and the how-to on the IBM homepage says so.
Somebody got some ideas here?
This method might also apply for video-freaks to tweak
the graphic card performance.
|6th January 2007, 10:40 PM||#22|
Join Date: Sep 2004
Location: Boston, Massachusetts
Blog Entries: 6
I'm a bit confused about the obsession over latency in this thread, for stereo playback it has relatively little relevance, and running a large buffer provides some protection against stream interruptions due to unexpected drive seeks and the like. (Particularly the case if you use the machine for other tasks simultaneously to serving music.)
The one situation where this might be annoying is when you go to select another song while playing another at which point the delay can be noticeable and annoying, otherwise it isn't.
"Extraordinary claims require extraordinary evidence." - Carl Sagan
|7th January 2007, 11:05 AM||#23|
I am talking about output buffers and its management. Buffers do cause latencies in general, that's a fact. If it's relevant or audible one will know, while playing with it.
It is a known fact that poor buffer management causes sound degradation. It'll depend how well your DAC or soundcard is able to cope with the more or less nonlinear stream caused by the driver.
This degradation increases the bigger the buffer gets, in case of poor managment or bad system setup.
If the buffer is too small you run in XRruns and perhaps maybe complete out of sync.
The buffer management, it is a software buffer, is also heavily
dependent on the system performance and interrupt handling.
If you have poor interrupt handling, you end up with less time for your sound device and inhomogenious timeslots to manage the buffer.
My goal is to understand the wole "black-box" PC.
You might want to read this, to get an idea that the PC-Black-Box
might not be perfectly configured by default:
You might also want to read this.
(Please, look at it as a general explanation how sw-buffers are managed and what problems they might cause)
You can look at it that way, that the audio-playback-application as source is comparable to the midi-device they are talking about!
In my case it makes audible differences on my system by changing the buffer size!
I get a good feeling that I squeezed most, at least for the time being, out of this particular "layer".
BTW. My machine, at least my audio-setup, shall act as a perfect source, for audiophile playback only! It is just configured for pure audio!
If I want to do different things with it I just boot up another kernel, distro, or even Windows .
|7th January 2007, 03:47 PM||#24|
Join Date: Dec 2006
Hi soundcheck, I am with kevinkr trying to figure out what it is the issue with interrupt latencies and buffers is, and especially the need for a real-time kernel. I agree that in the case of midi, there could be issues if the hardware setup is not optimized. But if you are only playing back audio, I really don't see how any of this matters. I think your setup would be great for sw-triggered, realtime "live" mixing of audio sources, and/or midi-generated audio mixed in. But for one source playback how does this matter? I read those articles and I am still confused why this is a concern.
When you say it makes a difference in what you hear when you change latencies and buffers, what specifically is it you hear? Can you measure it by spying on the bus or recording the output? I guess what we need is a specific situation or example that explains why too large of a buffer(in other words a default buffer size) is a problem.
The way I understand it is that if the buffer is too small on an overtaxed system, you get underruns under heavy loads, if it is too large, you get delays between songs if you change tracks. The sound card is in charge of generating its own timing for the Digital to analog conversion, and empties the buffer accordingly, triggering an interrupt when the buffer gets low.
I think the setup you are researching would be geat for live audio mixing or a studio recording setup which includes midi. I applaud your efforts in researching this, hacking is great fun and very rewarding and we appreciate hearing your results.
|7th January 2007, 04:30 PM||#25|
Join Date: Jun 2004
Location: Kerala, INDIA
Re: Linux Audio the way to go!?
Sure... open source software is the best place to find some fine quality audio software also. As it is open source... it will collect more of 'The entire human knowledge'... not limited to a few hidden heads working under a software company.
I got a low-fi Yamaha YMF724 + SigmaTel STAC9704 soundcard here (of course.. need to upgrade). The crystal on the card is 24.576MHz (24576/512 = 48kHz)... Like almost all sound cards.. here 44100 must be resampled to 48000 before DAC'ing.
So me went searching for a good SRC.. Examined various sampling rate conversion algorithms with RMAA spectrum analyzer software... The best two among them are 'Shibatch sampling rate converter (SSRC)' and 'sox polyphase'. Both shows almost no distortion spikes in the spectrum graph.. while others do... even 'mplayer -af resample:48000:0:2'.
And SoX uses 'libmad' for mp3 decoding... which is also in the category 'the best'.
$ sox what_a_wonderful_world.mp3 -s -w -r 48000 -t alsa /dev/snd/pcmC0D0p polyphase
Or... an insane push on the limits..
$ mkfifo tunnel.wav
$ sox neil_diamond_hello_again.mp3 -r 96000 -s -l tunnel.wav polyphase -width 2048 | play tunnel.wav
Or use the script given under for comfortably playing multiple files (eq: sox-poly *.mp3).
Copy the script to 'sox-poly' and 'chmod 755 sox-poly'. Then u are ready to ' ./sox-poly your.mp3'.
Polyphase sample rate conversion requires very high cpu attention. But I'm happy to dedicate the entire linux box for music.
SoX comes along most linux distros, read the manual for more...
-------sox resampling player script--------------------------------------
# The cleanest audio playback configuration using SoX
# by Rony B Chandran ( http://www.ronybc.8k.com )
# ver.0.3 - DEC2006
# sox uses libmad for mp3 decoding...
#device="-t ossdsp /dev/dsp"
device="-t alsa /dev/snd/pcmC0D0p"
echo "SoX polyphase resampling audio player script..."
echo "by Rony B Chandran ( http://www.ronybc.8k.com )"
echo "Hit 'Q' to quit and any other key to Forward..."
while [ $# -ne 0 ]; do
sox "$1" -s -w -r 48000 $device polyphase > /dev/null 2>&1 &
while pgrep sox > /dev/null && [ -z $zin ];do
read -t 1 -n 1 -s zin
echo -n "-"
pgrep sox |xargs -n 1 kill >/dev/null 2>&1
if [ "$zin" = "q" ] ;then
echo "That was a Q.. bye..."
-------script ends here-------------------------------------------------
The coolest website on the planet..!
|7th January 2007, 10:35 PM||#26|
Join Date: Jun 2006
- Flushing the buffer should be an easy enough task, And that would take care of the delays.
If you accomplish all you think, you think to little.
|8th January 2007, 10:24 AM||#27|
Re: Re: Linux Audio the way to go!?
Though I like the mkfifo/tunnel.wav thing. Could you give me/us a short explanaition of what you're doing there?
My way to do SRC is converting my .wav files with "Voxengo R8Brain Pro" offline.
The demo lets you convert one minute of a track. That might be sufficiant to hear
a difference! Just give it a try.
I compared Shibatch realtime sampling (which btw J.River also uses for realtime SRC) to my offline Voxengo SRC.
I just strongly recommend to give offline SRC a try.
|8th January 2007, 12:55 PM||#28|
Join Date: Dec 2004
I can see where your coming from, basically treating the OS chain of buffers and protocols as if it were the audio chain and therefore looking to remove all unecessary components i.e. buffers. I have no idea whether this is necessary or not, but my current feeling is that as long as the last buffer delivers to the soundcard as expected, surely everything before this is irrelevant as long as the data is not corrupted or changed? However I have been looking for discussion like this for a long time and am enjoying reading your efforts.
In your quest for the path of least resistance for the PCM stream, choice of player could be important.
I noticed that xmms is no longer maintained. In fact to the extent that Gentoo have now masked it out of their repository as they were having to do substantial work on it themselves to include it in their current distros as it doesnt support GTK2 libraries.
I have read comments that players using engines such as xine and gstreamer, which covers many of those currently available, including Amarok, are bloated due to the fact that they support both audio and video. XMMS has its own audio engine which would be optimised for audio only, but although still used by many, it is probably better to find an actively developed player.
This article points towards audacious or XMMS2 as the most suitable replacements for xmms. XMMS2 is usually controlled by a client on another machine.
Alsaplayer seemed like a good option as it aimed to make the most of ALSA, but it too has not been updated for a number of years. I ran into difficulties trying to install it on ubuntu. LAMIP did look promising also - foobar2000 GUI etc, but development has slowed here as well with a number of features still to be done. Along side XMMS2, Music Player Daemon looks like a good option as they have their own audio only engine, again may not be the best choice for a non remote controlled system. MPD (and xmms2) is specifically designed to be used as a headless hifi rack component. The XMMS2 site has two interesting articles with comparisions to both MPD and gstreamer, which is actually the source I am referring to when I mentioned bloatedness of gstreamer.
Aqualung also seems to be active and are clearly focussed as a project on providing a good sounding player e.g. gapless, quality src etc. It looks to be quite like foobar, and the support of ladspa plugins for dsp has a lot of potential.
I am sticking with windows just now as the foobar xo plugin is proving too useful and easy to use in developing my diy speakers. Xlobby can provide foobar with a mediacentre frontend.
Any comments on player audio engines?
|8th January 2007, 02:31 PM||#29|
I guess you figured it out.
All my findings are indeed most probably very much related to my USB-DAC
and its PCM2707 interface. (At least that's my conclusion, since nobody around
here seems to confirm my little investigation results )
The PCM2707 used as a USB2I2S converter you'd call a very simple well-perfoming PCM-router more or less. The converter delivers what you'll feed. This is more than evident looking at the results I am getting. I mean - the improvements I get are 100% related to Jitter or drift.
My aim is here to feed the purest signal without drifting bits or samples, as far as possible on an USB connection.
A fully synched master-slave , we discussed it earlier, scenario to get the clock or rather the buffers of the PC and DAC synched sound like a more promising solution on a first glance.
Still you'd get other things in the stream: another soundcard (PC-out), spdif, cables, buffers, clocks connectors asf.
In the end a solution as discussed in the other thread (PC perfect source) to have a PCI card delivering the precision clocked I2S stream right to your DIY DAC, might be the "absolute" solution by looking at the "PC as source" scenario.
Why don't I buy myself a decent soundcard, such as Lynx, RME asf., I could ask myself? This wouldn't be DIY, and most probably wouldn't deliver exactly the highest quality solution I am looking for.
Regarding Linux players:
When it comes to pure PCM playback, most of the players are just using ALSA as the audio engine, for pure PCM streaming. Doesn't matter if you look at XMMS, XMMS2, XINE, Amarok (using Xine), mplayer, audacious or anything else.
I looked up most of them and found that there are indeed differences when it comes to SRC (in case ALSA DMIX is not used), supported formats etc.
When it comes to .wav pcm-playback 16/48/44.1 they all just tell ALSA ... here is a pure PCM stream coming use these parameters to handle it!
In my case, having a usb-snd-card even Jack would use ALSA as interface.
For the time being XMMS is my choice, even if no longer supported. It plays directories, files and playlists.
I can configure almost all ALSA buffers and interface parameters I need. And it also allows me to run it in Realtime. XMMS is also a very lean build compared to others.
The only feature XMMS lacks is full file buffering.
That's why I play all files from RAM by copying the tracks to /tmp,
My /tmp fully resides within RAM.
tmpfs /tmp tmpfs defaults,size=1500m 0 0
in /etc/fstab -- you dynamically allocate 1,5 gig of RAM or any other size you're able to spare to /tmp.
You establish an easy RAMdisk this way and mainly avoid also harddrive access on temporary files while playing back. Just copy your .wav-files over to tmp, start playback and listen.
Your HD-LED stays dark all the time! Try to get this configured under Windows!
Rony called his apporach "Insane push to the limits" -- I guess am getting close to it!
|9th January 2007, 09:06 AM||#30|
Join Date: May 2003
Aqualung is great
I got around to compiling Aqualung today from source since there are no recent Ubuntu/Debian packages that I know of. All I have to say is that it's great. The UI could use some work since lots of information is displayed on one line forcing you to make the player window very wide to be able to read it all. A note to anyone trying Aqualung, be sure to read the manual to see how RVA and the resampler work. Using the command line, you can resample anything the player will play to any frequency your soundcard supports using very high quality resampling algorithms (at the cost of high CPU useage of course).
In conclusion, Aqualung is great
|Thread Tools||Search this Thread|
|New To Site?||Need Help?|