Linux Audio the way to go!?

[soundcheck]

Realtime benchmarking

Hi folks.

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.


Cheers

 

[kevinkr]

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.

Just wondering..

 

[soundcheck]

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.

Just wondering..

So far, the only one talking about latencies in terms of audio playback is you! Nobody is talking about latency in terms of "midi-in-out" here. At least I am not.
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:

http://www-128.ibm.com/developerworks/library/l-hw2.html


You might also want to read this.

http://www.rme-audio.com/english/techinfo/lola_latec.htm

(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 .


Cheers

 

[lm317t]

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.

 

[ronybc]

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--------------------------------------

#/bin/bash

# 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
echo "SoX polyphase resampling audio player script..."
echo "by Rony B Chandran ( http://www.ronybc.8k.com )"
echo
echo "Hit 'Q' to quit and any other key to Forward..."
echo

while [ $# -ne 0 ]; do
mpginfo "$1"
echo $1
sox "$1" -s -w -r 48000 $device polyphase > /dev/null 2>&1 &
sleep 0.1
zin=""
while pgrep sox > /dev/null && [ -z $zin ];do
read -t 1 -n 1 -s zin
echo -n "-"
done
echo ""
pgrep sox |xargs -n 1 kill >/dev/null 2>&1
if [ "$zin" = "q" ] ;then
echo "That was a Q.. bye..."
exit
fi
shift
done

kill 0

-------script ends here-------------------------------------------------

 

[eleson]

...
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.
...

I've seen this from times to times, and also noticed it in equipment, but it still puzzles me;
- Flushing the buffer should be an easy enough task, And that would take care of the delays.

 

[soundcheck]

Re: 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...

I wouldn't call MP3 sound an "insane push on the limits".

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.

http://www.voxengo.com/product/r8brainpro/

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.


Cheers

 

[rossco_50]

Soundcheck,

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?

Ross

 

[soundcheck]

Soundcheck,

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.

Ross,

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.

By entering

----------

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!


Cheers

 

[DcibeL]

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

 

[soundcheck]

Re: 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

How about a quick "HowTo" about building Aqualung for us Ubuntu freaks? Any traps? You could make life easier for us!


I am just setting up Jack and Alsaplayer-Jack.
The Jack audio interface for ALSA is the best and fastest around and it won't slow down ALSA, according to the Jack Homepages, The configuration options of Jack allow easy finetuning of your sounddevice. Beside that the whole setup is capable of realtime operation.
Let see how it'll sound.


Cheers

 

[rossco_50]

Linux squeeze box

Apologies for posting away from the more technical side of linux audio set-up, but I came across this at the other day http://www.herger.net/slim/detail.php?nr=763

Slimcd a live cd based on damn small linux with slimserver and softsqueeze pre configured essentially giving you the functionality of a squeeze box.

Im going to have to give up on xp as the box Im setting up for audio based on a 700mhz Via cyrix iii. XP appeared to be working reasonably but has slowed down substantially to being unuseable with the addition of drivers and plugins. Cyrix's are crap for anything more than playback - giving up on the xo just now.

Moving to Linux - I suspect ubuntu may also be too bulky for the cyrix - xubuntu is another option. however, I have noticed that many low spec users have to revert to the 2.4 kernel distros, such as DSL and have to use low resource player/servers like MPD. Unfortuantely DSL requires alsa to be installed.

Many insist a correaltion between high spec processors and good sound - maybe. I chose the cyrix as it only needs a heatsink and will have relatively low EMI due to low heat output - also only cost £5. I will keep going with it just now.

Soundcheck, perhaps a how-to- on ubuntu alsa/real time patching configs would be good, but perhaps when you have plateaued at your optimum solution?

Ross

 

[DcibeL]

Re: Re: Aqualung is great

How about a quick "HowTo" about building Aqualung for us Ubuntu freaks? Any traps? You could make life easier for us!

Well I'm no good at writing HowTo's but I'll give an explanation for people who already know how to work their OS

The compiling page gives you pretty much everything you need to know to compile this program. I just started up Synaptic and searched for all the development packages I wanted in the list. Packages with -dev at the end is the source code required for compiling programs, so you need to enable the source repositories. I wanted to be able to edit metadata and be able to uninstall the program easily if I didn't like it, so here's what I did:

./configure --with-metaedit
./make
sudo checkinstall -D

The last line basically does the same as "make install" with the exception that it will build a .deb package and install that. The .deb will not include dependancies so it doesn't make something you can redistribute to others, but it does make it very easy to uninstall.

Good luck.

 

[soundcheck]

Re: Linux squeeze box

Apologies for posting away from the more technical side of linux audio set-up, but I came across this at the other day http://www.herger.net/slim/detail.php?nr=763

Slimcd a live cd based on damn small linux with slimserver and softsqueeze pre configured essentially giving you the functionality of a squeeze box.

Im going to have to give up on xp as the box Im setting up for audio based on a 700mhz Via cyrix iii. XP appeared to be working reasonably but has slowed down substantially to being unuseable with the addition of drivers and plugins. Cyrix's are crap for anything more than playback - giving up on the xo just now.

Moving to Linux - I suspect ubuntu may also be too bulky for the cyrix - xubuntu is another option. however, I have noticed that many low spec users have to revert to the 2.4 kernel distros, such as DSL and have to use low resource player/servers like MPD. Unfortuantely DSL requires alsa to be installed.

Many insist a correaltion between high spec processors and good sound - maybe. I chose the cyrix as it only needs a heatsink and will have relatively low EMI due to low heat output - also only cost £5. I will keep going with it just now.

Soundcheck, perhaps a how-to- on ubuntu alsa/real time patching configs would be good, but perhaps when you have plateaued at your optimum solution?

Ross

Hi Ross.

I'll take Slimdevices as a source for some ideas.

When it comes to the X environment you are right. The default environment of Ubuntu uses quite some resources and it's pretty slow from Unix perspective. Especially if you havn't done the realtime patch. I got Xfce 4.4 on my to-do-list. I tried a slim X environment earlier. These are lightening fast! Xfce is supposed to be fast and comfortable at the same time.

One after another. It's really amazing and fun how the whole thing evolves
ones you start with it!

As soon as I am ready with my setup, if that ever happens, I'll give directions!
Realtime patching is extremly easy though ( there some great and working how-to's out there).
The main-issue is to get the configuration of the kernel right. Once you have your config file right it is just a matter a time. It can take up to 2h processor time to get the kernel compiled. On my core duo, 2.16 it took one hour. I had to do it a couple of times though.


Cheers

 

[ronybc]

about the push

I got here a card with max. of 48kHz, 16bit playback. and i'm doing...

$ mkfifo tunnel.wav
$ sox neil_diamond_hello_again.mp3 -r 96000 -s -l tunnel.wav polyphase -width 2048 | play tunnel.wav

here...
The first 'sox' converts and resamples the input 44kHz audio (.mp3 or .wav) to 96kHz, 32bit PCM. Then it is feed to the next 'sox' (play) via a pipe... this one downconverts the samples to 48kHz,16bit so that my poor sound card could DAC it.

What I'm trying to do is to keep the bit depth as high as possible and same in the processing chain. 'libmad' can emit 32bit samples... do the resampling at this high resolution (not sure... whether this will aid quality or just waste some cpu and memory)

you can see what actually happens by using verbose mode : 'sox -V' and 'play -V'

'sox polyphase' leaves almost no distortions.. the result was very clear to me. Using verbose mode (sox -V) you can get the idea, what polyphase does. Also see this SRC test results

 

[rossco_50]

Real time

Soundcheck,

I am now using Puppy linux. Its only 80mb in size and the whole system loads into RAM from whatever media it is held on. It also has a 2.6.18 kernel, which actually works very well on my low spec processor, other distributions using 2.6 kernels, like slax and dynebolic did not for some reason. Puppy differs where it was built from scratch, not just an adaption of knoppix or another system.

the 2.6.18 kernel has real time built in, so no need for recompiling with patches, just enable. Still not convinced this would improve sound though, but may improve system speed on my limited processor. Alsaconf is a menu option and recognised my soundcard imediately.

In the main menu is an installer utility where you can chose to install the system from the live cd to various types of media. flash card in an ide adaptor is one, which I think I will do to have a completely silent and low powered system. The way in which the installer works ensures that read/writes to the flash card are reduced to prolong its life. Would be a fairly simple excercise to create a additonal virtual memory with the remaining flash capacity for full file buffering.

The included media player is gxine - very basic. Installing programs is very easy. People on the forum have compiled aqualung, xmms and audacious as dotpup modules which are installed more easily and quickly than any other system I have used. Seems to be very easy to build your own modules as well.

Ubuntu is still on 2.6.17, which I think has some realtime capability, but does need patched to get the full effect.

Only messed about with it for a short time, but Im very impressed with it so far.

Ross

 

[soundcheck]

Re: Real time

Soundcheck,

I am now using Puppy linux. Its only 80mb in size and the whole system loads into RAM from whatever media it is held on. It also has a 2.6.18 kernel, which actually works very well on my low spec processor, other distributions using 2.6 kernels, like slax and dynebolic did not for some reason. Puppy differs where it was built from scratch, not just an adaption of knoppix or another system.

the 2.6.18 kernel has real time built in, so no need for recompiling with patches, just enable. Still not convinced this would improve sound though, but may improve system speed on my limited processor. Alsaconf is a menu option and recognised my soundcard imediately.

In the main menu is an installer utility where you can chose to install the system from the live cd to various types of media. flash card in an ide adaptor is one, which I think I will do to have a completely silent and low powered system. The way in which the installer works ensures that read/writes to the flash card are reduced to prolong its life. Would be a fairly simple excercise to create a additonal virtual memory with the remaining flash capacity for full file buffering.

The included media player is gxine - very basic. Installing programs is very easy. People on the forum have compiled aqualung, xmms and audacious as dotpup modules which are installed more easily and quickly than any other system I have used. Seems to be very easy to build your own modules as well.

Ubuntu is still on 2.6.17, which I think has some realtime capability, but does need patched to get the full effect.

Only messed about with it for a short time, but Im very impressed with it so far.

Ross

Sounds interesting. I'll look it up.

I am running a 2.6.19.1-RT15 Kernel. You just download the kernel from kernel.org and patch it . There is already even a 2.6.20 available.

I won't step back to an older revision. Especially on newer machines this is
not recommended.


-----------------------


I did some testing recently.

Jack, Alsa and Alsaplayer vs. XMMS and Alsa all in full realtime.

Jack didn't allow me to select less than 64 frames as buffer, which led to a Latency of 2,67ms. The message I got from Jack was like "Alsa wouldn't allow less than 64frames?" Perhaps I've done something wrong here.

For the time being I stay with XMMS.
Jack and Alsaplayer, both played in Realtime, gave me more distortions than XMMS and ALSA. I have to admit though that driving XMMS at a buffer size of 10 needs really a stripped down system. There are plenty of incidents, which can cause XRUNS.
On the professional music pages they e.g. recommend to let ACPI run all the time, meaning "Fan On" at full speed all the time to avoid blocked processes. ( I just compiled my kernel accordingly. Let see how this works)

My upcoming solution to the ACPI issue: http://www.mcubed-store.com/catalog/index.php?language=en fully passive cooled.
Ultra-Cool Design.

I think the buffer or rather the IRQ issue is really an issue.
Looking at the "long" (I mean 3ms are still 5times better than Windows! )
gaps produced by the PC IRQs, if not configured properly.
No wonder that the sound deteriorates on DACs like mine.

I am still not there yet!

-----------------

BTW

I filed trouble reports at Audacious because of the, from my perspective, lacking features:

Realtime support
Buffer limit of 200ms

The guy in charge was answering, "he is not intending to change anything, they are not XMMS." Sounded quite rude to me!

Funny though. If you look up all the config files, they pretty much still look like XMMS to me! However.


I got plenty of things to try here.

Cheers

 

[soundcheck]

Re: Real time

the 2.6.18 kernel has real time built in, so no need for recompiling with patches, just enable.

Ross.

That's not the whole story.
Without introducing the "Ingo Molnar" RT-patch you can not set your system to full realtime operation. The patch introduces an option called "Complete Preemption". The default kernel delivers three RT options by default refering very much to the desktop only!
You also have to change the timer from 250 to 1000 when running RT, which gives you a much better precision and response time. This was not configured by default in my case. Default is 250Hz.

I had a look at Puppy Linux pages. I am wondering if one will manage to do hacks
as described above without in-depth Linux knowlegdge. Still I think it's worth a try.

Cheers

 

[rossco_50]

I have always wondered what the difference is between Ingo Molnar, andrew morton (Demudi) and the Con Kovalis (Dynebolic) low latency patches. All are mentioned with respect to audio set-up but Im unsure whether there are conflicts between them and which offers the best performance. They are perhaps even the same thing for all I know. Again, im not convinced of any correlation between these patches and audio quality - but will try later when I have everything else set up.

Im not experienced enough to say whether puppy is as 'hackable' as fully blown desktop distros like ubuntu - but it seems that I can add pretty much any program or library I would want to, and there is chat in the forums about patching for low latency (in audio terms, someone has done this) and I seem to remember a section in the documentation about recompiling and remastering. At least for a mini distro, it is very flexible. going to try Damn small linux as well, there is still some heavy cpu load with puppy on fairly simple tasks.

That does seem like a fairly agressive response by the audacious guy. they maybe get a lot or requests for old xmms features, as they are often compared and adacious is still active. They are also two (possibly) three forks away from xmms.

Get yourself aqualung, would like to hear how it compares to xmms and alsaplayer.

Ross

 

[tubee]

I work one year now with Ubuntu, first 5.1, and now 6.06
Works to full satisfaction on an old 616mHz overclocked machine with 512mB ram. My daughters like the Linuxes a lot more then windoze.
Have installed Xubuntu too on an other very silent Compaq, and tried Puppy linux from cd.
But in Ubuntu i didn't get all working yet, for example i cannot play video's. Also Frostwire isn't working due older java.

Want to build an USB-I2S interface in time for dig. audio to a dac. But the 616mhz must get passive cooling then first.