Linux Audio the way to go!?

[soundcheck]

I just installed Xubuntu and the realtimekernel. Xubuntu uses the lean XFCE
GUI. You won't miss any features.

The XFCE GUI without realtime-kernel is already much faster than "Gnome" Ubuntu with realtime-kernel.

I'll stay with Xubuntu. That's what you need in the multimedia area.

Cheers

[Gopher]

What the hell are you people talking about? Go and listen to some music instead of fiddling around with this or that kernal version Ubuntu Edhy v2.001n45 with Gumtree dll file mods or whatever.

[rossco_50]

Good point.

[soundcheck]

Originally posted by Gopher
What the hell are you people talking about? Go and listen to some music instead of fiddling around with this or that kernal version Ubuntu Edhy v2.001n45 with Gumtree dll file mods or whatever.

Many people around here fiddle around with tubes, capacitors, inductors, resistors asf since years.
There are even more people around still trying to mod
outdated CD-players, (pre- )amps, speakers.
Why don't you post a general post, telling the whole diy-audio
community to rather listen to music instead of fiddling around
with above.

There are also quite some people around here accepting the PC
as a black box MS-Windows based system and accepting it the way how it works. These people usually enjoy listening to MP3s over PC-speakers. Fair enough.

But there is also a very small community, trying to make an audiophile source out of the PC. This topic hasn't been
discussed very much for now. I strongly believe it is worth
discussing it.

As you might have seen, there are a lot of people around here, confirming that Linux is the OS, one should go for when it comes to Audio and Multimedia applications.

When it comes to postprocessing audio-data the platform bears a huge potential.
There are quite some people around, who use e.g. Brutefir etc.
to do the filtering/crossover/convolution already in the digital domain. These type off applications do need maximum
performance to avoid sound deterioration. That's what I am after.

Don't forget most of the audio and mulimedia Linux distros are highly tweaked realtime setups.
(Unfortunaletly these don't run on all PCs or makeing tweaking almost impossible.)

Coming up with these (your) kind of BOLD statements is a 10s job. Coming up with real constructive input to develop the story is a different story.

Enjoy your music and avoid reading these kind of threads, what just keeps you away from listening to music and keeps me away form getting my PC/Linux up2speed.

Constructive feedback or contribution is apprectiated and always welcome.

Cheers

[tubee]

There are also quite some people around here accepting the PC
as a black box MS-Windows based system and accepting it the way how it works. These people usually enjoy listening to MP3s over PC-speakers. Fair enough.

Agree. I worked 8 to 9 years with M$ products, now 1 year Linux. All those m$ years wasted to keep the pc running: install firewall, updates, service packs, virusscans, virusupdates, spyware checkups, register cleaning, defragmenting HD's, blue screens, missing ntldr's, new installs etc. On Linux the pc works for me instead of the other way round.
Linux has some faults too, but compared to win only minor things.

[soundcheck]

Originally posted by ronybc
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)

[/URL]

Hi Rony.

Interesting. Slowly but slowly I see the potential the way you
fiddling around with the data-stream.

1. Do you have an idea if the 32bits are processed as floats ?
2. How can I possibly apply replay gain to the data stream, Is there a Sox feature, gain integrator?

Background: How2 establish a high quality volume control in the digital domain.



Cheers

[rossco_50]

Rony,

Just noticed that you seem to be resampling to 48khz in the pc to try and avoid the affects of the soundcard resampling. I think in actual fact that soundcards that do resample do this to all material, even if the stream is 48khz in the first place. Therefore this may not have much of an effect except to add a further insatnce of resampling where there need only be one.

Soundcheck, I have now done a hd install of puppy and will patch for real time premption. Some level of preemption is available in the kernel as standard, but not full on - as you quite correctly pointed out previously. I have been advised to apply the Con Kovalis patch as well to further the effect. Definitely we are still to really determine, even in theory, if these patches will improve audio quality, but it does seem like a good idea to give audio applications priority over other systems and assign as much cpu time as possible. It should also notably improve the performance of my low spec system which at times gets sluggish at the moment.

Is it maybe possible to route audio using jack from xmms through ardour and control volume through it? The ardour engine is 32bit floating point and if it can be determined that volume control is done within the engine this may give you the performance you are lookimg for?

[soundcheck]

Hi Ross.


The RT story goes even further. I read somewhere that a combination of
Kovalis and Molnar would be even better.
As an "insane push to the limits" you should have a look at realtime distros,
such as RTLinux.

The overall key issue behind above is to avoid process lock-ups, which can easily happen in a realtime environment, since all tasks are still handled sequential.

As long as you just run your audio application and don't touch your system while playing back everything should be OK.

For the ones without RT-patched Kernels, you could try the "nice" (command,
which can lift-up your task priority.

Start your application from command line:

$sudo nice -n -10 xmms

The range goes from -20 to +20, where -20 is the highest priority (but should be avoided ). -10 should work quite well!

The problem: You won't speed up ALSA and the soundcard driver.


When it comes to volume control, using ALSA/JACK/ARDOUR/XMMS might work.
Though I doubt that the sound improves by chaining up more and more applications. The other problem. Many of the applications running DSPs using
/dev/dsp as device. AFAIK this is only supported by OSS ( the old sound system under Unix). In the end you might run an OSS emulation under ALSA. This is
getting too complex.

There is still a lot to play around with!

Cheers

[soundcheck]

Hi folks.

Today I digged out the "Ecasound" sound-processing tool.
It is quite easy to implement. I spent half a day to analyse it.

The tool just comes with a commandline interface.
The missing GUI doesn't really mean anything when it comes to the actual performance of this little tool. ( I think bulky GUIs are just wasting processing time anyhow. What I realized, the more you get into the Linux-world, the more you appreciate real fast command line operations. )
The application is highly optimized for realtime operation and manages all data processing at 32bit/float. I read that even Ardour is not able
to deliver the numerous features provided by Ecasound.

After some listening sessions today, I just can state here that this tool beats easily my favorite alsa/xmms setup. Again a step forward, Wow!
My new reference as "single track player".
(I need to write a script, to be able to playback multiple files from /tmp --
Any hacker around who can give some hints?)

For the ones interested in trying ecasound:

ecasound can be found in the Ubuntu repositories. It is easy to install with synaptics. Just search for it. Ecasound seems also to be well maintained.

Below the command line options, which gave me best results for now:

$ ecasound -r -c -b 1 -f:16,2,48000 -i:test.wav -ea:50 -o:alsa,hw:0,0

That's how I process my 48kHz base-material. Without using the -f option it processes automatically 16/44,1 material.

-r stands for realtime
-c stands for interactive mode. By typing start or stop you can manage the playback at the interactive mode new prompt.
-b buffer size in samples. I can run it with 1 sample buffersize. You might try larger buffers first (e.g. 256)
-ea:50 configures the volume-level at 50 %
-o you need to fill in the alsa device id. It might be hw:1,0 instead of 0,0


Once installed with synaptics you should do following to prepare ecasound for realtime-operation

cd /usr/bin
sudo chown root.audio ecasound
sudo chmod 4750 ecasound

Make sure that you got the "audio" user group configured as the "realtime" group in /etc/security/limits.conf (the last 3 lines should look like below)

@audio - rtprio 99
@audio - memlock 250000
@audio - nice -10

So far so good. Let me know what you experienced!

Cheers

[SunRa]

Hi soundcheck,

just installed Xubuntu and the realtimekernel. Xubuntu uses the lean XFCE

did you tried this one: Vector Linux ?

They now say it's the fastest distro.

I gave it a try some time ago, and it's very fast, especially on not so fast pc's. In a week or so I'll try xubuntu too (just to compare them), and start playing with brutefir, jack, and drc, ..

I am now using dynebolic but I don't have access to their web-site. Don't know why... I like the distro, but I'm yet on learning linux to properly evaluate it...

Good luck !