Linux Audio the way to go!?

[UnixMan]

What do you thing of the solution proposed on post #988?
Is it not interesting to you or not enough well explained?

If someone is interested i can open a new thread to talk about this stuff.

[/B]

yes! Do it, please.

 

[soundcheck]

Hi folks.

I just installed a Linux MINT6, it is based on Ubuntu 8.10. Some time ago somebody brought it up over here.

The community acceptance is quite high. On distrowatch.com they are already on rank 3, right after Ubuntu and Suse.

No wonder why. Look and feel is really nice.

To me it looks much more professional (serious) then a stock Ubuntu. Under the hood you'll find of course the same stuff as you'd find it in Ubuntu.

rt-kernel is also available.

If you look for a new fresh look and feel - give it a try.


Cheers

 

[anbello]

From UnixMan:

yes! Do it, please.

I started a new thread here

Ciao
Andrea

 

[Telstar]

I think there are many other people interested about that... (me, for one! ) so IMHO better open another thread instead.

I posted it here:
http://www.diyaudio.com/forums/showthread.php?postid=1770500#post1770500

 

[Onvinyl]

I have problems with my real time ubuntu studio installation. (8.04) When running mpd in real time mode, the main terminal gets flooded with error warnings, and the audio has a lot of dropouts and sounds bad. Plus, as already mentioned, I can't play radiostreams, but this is probably another problem.

This is not the worlds cutest error description, but maybe someone has an idea?

Rüdiger

 

[soundcheck]

You should think about upgrading to 8.10. Makes life easier.

 

[Onvinyl]

I'm not familiar with the upgrading process. Do you think, it will solve my problems? Will the upgrade leave newer software releases intact (mpd, alsa, sox etc.pp.)? Will I have to reconfigure my network (vncserver, samba etc.)?

Will it leave the customizing intact? (No xwindow at startup, for instance)

It was a whole lot of work to set it up. Plug & Swear!

Rüdiger

 

[soundcheck]

Usually the upgrade is easy going.

However:

Make yourself familiar with the backup and restore routine before you start your upgrade. This is for sure more complex and risky then the upgrade itself.

Cheers

 

[phofman]

Onvinyl,

please elaborate more. What error messages are you getting? What is your soundcard? What are your PC parameters? What is your audio usage scenario (playback or recording/mastering too)?

I have experienced problems with sound drivers/hardware behaving differently in the ubuntu studio RT kernel compared to the generic kernel in the same ubuntu version. Unless really needing low latency, I personally would not use it. I am writing this on ubuntu studio with the generic kernel.

http://mailman.alsa-project.org/pipermail/alsa-devel/2008-May/008096.html
http://mailman.alsa-project.org/pipermail/alsa-devel/2008-April/007614.html
http://mailman.alsa-project.org/pipermail/alsa-devel/2008-May/007624.html

 

[soundcheck]

Hi folks.

I lust started up an Ecasound Wiki.

http://www.diyaudio.com/wiki/index.php?page=LINUX+Audio+Ecasound

I try to avoid redundant information. You'll find plenty of stuff and examples on the ecasound homepages or manpages.

For now I outline how to compile it from sources, how to get it to work with MPD
and how to get it remote controlled e.g. volume control via TCP and netcat.

Cheers

 

[1audio]

What does ecasound bring in terms of features and performance? If all I want is "bit perfect" output, which I can now get with MPD going directly to Alsa, is there something that ecasound does that would be helpful?

 

[soundcheck]

You can do a hell lot of stuff with ecasound. I'd recommend to read the manpages or homepage.

On many systems it just sounds better then the MPD engine.
It's heavily realtime optimized for lowest latency. Works also great with Jack.

If all what you want is "bit-perfection" on the output, stay with MPD alsa-output to "hw:x.x".

Don't forget that "bit-perfection" is not saying anything about jitter. It'll depend heavily on the
receivers ability to cope with this or that amount of incoming jitter, if we start talking about soundquality.

I use it as engine within my ecasx player.
With the TCP interactive interface i can control it now externally and also from any place in the network easily.

 

[anli]

Originally posted by soundcheck On many systems it just sounds better then the MPD engine.

Would you, please, be more elaborate? On which systems? What is and why better? And how does a software influence a hardware jitter?

 

[1audio]

The jitter issue is related to the construction and design of the pc sound interface. The Juli@ I use has a direct crystal controlled output but some use pll's that can be influenced by processor noise etc. a lot more. My current target DAC is the Berkeley Audio dac which is very good at reducing incoming jitter and has some other stuff they don't talk about to make it sound good. But even so they admit that jitter in the chain will degrade the audio even with all their tricks. This is the same group that created HDCD and the Pacific Microsonics ADC/DAC system.
I'm not sure I understand how more software in the chain can reduce jitter but I'm all ears. . .

 

[phofman]

...but some use pll's that can be influenced by processor noise etc.

That is perfectly logical. I just do not see how running in real-time reduces processor noise. On the contrary, I can see how the increased CPU activity and frequent interrupt handling increases the processor noise.

I'm not sure I understand how more software in the chain can reduce jitter but I'm all ears. . . [/B]

I do not understand how more software in the chain can increase the output jitter of a sound card (apart of the power supply impact which is pretty difficult to treat in software) provided the card gets data on time.

 

[LinuksGuru]

Linux Help

Hi! I am use Linux since 2000, mostly as server platform + as home workstation. Additionally, my home Linux PC serves as media center for audio and video conversion/playback. My experience with all that stuff was not absolutely smooth, time to time I am having problems, but this I think is normal.

Currently I have SuSE Linux 11.1 64-bit running on Intel Quad Core, Gigabyte Ultra Durable m/b, and old but trusty SoundBlaster Live 5.1. Please note I am not a fan of 5+1, 7+1 or whatever else 10x speaker setup, I am use a pair of 4-way high-sensitive (98 dB/W/m) Technics SB-G710 (with 36 sm woofer) + vintage vacuum tube Pioneer SM-83 (for music only) and Sansui G Pure DC amps. With that system I can achieve what literally translated from Russian called something like "live holographic sound".

I am was thinking to build separate miniature media center box (aka Apple TV clone) on Intel Atom, but disbanded this idea because small uATX mainboards do not have enough expansion slots for all things I want (no HDMI for example). Moreover, SuSE Linux 11.0 and 11.1 had mystic issues with Intel Audio.

I can start a new thread where you can ask me Linux-related questions. Please note I am not a designer of audio or electronic equipment, my area of professional expertise is Mac/Linux in DTP/printing industry.

You can check my old Mac/Linux stuff here (not related to audio in any way):
link

And vintage audio pages here:
link

 

[1audio]

LinuksGuru

I'm a little confused. You can get uATX and even miniITX motherboards with onboard HDMI and support for 7.1 audio. They are starting to have enough video horsepower to anything an AV system would want. Perhaps a little more on your goals would help us all work together and share insights. I'll be happy to share my almost current knowledge of media motherboards. I need assistance in packaging a Linux that will be a very focused high performance music player.

 

[soundcheck]

Th
I'm not sure I understand how more software in the chain can reduce jitter but I'm all ears. . .

Hi there.

Now there're two of us. For clarification: The extra SW is not reducing jitter. It is just not causing jitter.

One thing I can state in general: The PC is a non-linear animal, causing non-linearities and distortions at every "corner".

The more lean it gets the less problems you'll experience. That's correct !
However the most important thing is that you have the best software at the end of the chain (last point of control) before it leaves the PC. I havn't really checked, if there is a difference between solo ecasound and the mpd/ecsaound combo.

In general SW can heavily mess around with a datastream. Non linear timers ( don't believe that 1ms slots are always 1ms) and daisy chaining of timers, interrupts, buffers, drivers ( and its configurations), poor code, bugs and ... God knows what else, can cause non-linearities to a real-time data stream on the software side. Of course there is usually a very close correlation to the PC-HW, just looking at the SW side won't be sufficient.


I havn't seen anybody in any forum, who was able to proof what's going on inside a PC based digital chain. Nobody is covering the whole story.
The majority of the so called "specialists" are usually picking this or that argument but really never present a holistic view.

I think the "Trial and Error" method following a certain direction - something like - "Less is More" - is IMO for the time being a nice approach.
If I'd followed phofmans arguments , I'd be still listening to a system running at <80% of its potential.

More than two years ago I started to switch off everything inside a PC , using a RAMDISK and a realtime kernel. This is only possible under Linux.
Today people are raving about battery driven headless and fanless Fitpc's, lean kernels, SSDs and stripped down OSs and yes also ramdisks , because these just perform better.

The discussions about this will probably never end, since the SW and HW is always changing and everybody has a different setup. It is useless to argue about it.

My intention is to share some findings over here. Arguing about it is just a waste of time.
Everybody can try what I am bringing up here in a 10minutes exercise with no cost associated to it.
If there are people coming to the same conclusions as I do, I'd really prefer to discuss or better speculate why it is the way it is, instead of arguing about snake-oil and voodoo.


Cheers

 

[soundcheck]

LinuksGuru

I'm a little confused. You can get uATX and even miniITX motherboards with onboard HDMI and support for 7.1 audio. They are starting to have enough video horsepower to anything an AV system would want. Perhaps a little more on your goals would help us all work together and share insights. I'll be happy to share my almost current knowledge of media motherboards. I need assistance in packaging a Linux that will be a very focused high performance music player.

Hi there.

I am looking for a small board that covers at least:

1. 4GB RAM
2. PCI-e slot (for soundcard)
3. Fanless
4. Preferably 12V supply
5. Gbit-LAN
6. DVI-D/HDMI (1920*1200)
7. PS/2 ( To avoid USB keyboard and usb-mouse)

The new Nvidia ION seems to be a nice platform. It comes with CUDA capability, which can be used for DSP activity. Perhaps the HDMI IF can be used for multichannel PCM.

However above feature list is not really covered by ION

Any recommendations?

Cheers

 

[phofman]

...For clarification: The extra SW is not reducing jitter. It is just not causing jitter....

How do you know that? And please do not tell us you just hear it.

In general SW can heavily mess around with a datastream. Non linear timers ( don't believe that 1ms slots are always 1ms) and daisy chaining of timers, interrupts, buffers, drivers ( and its configurations), poor code, bugs and ... God knows what else, can cause non-linearities to a real-time data stream on the software side. Of course there is usually a very close correlation to the PC-HW, just looking at the SW side won't be sufficient.

There is NO real-time (i.e. isochronous) data stream on the Linux PC side, no matter how hard you try. And there does not need to be any. I have repeated this many times, you just explicitly refuse to learn how things work in your PC.

If by that 1ms timer you mean USB, it is a HW timer, absolutely independent of the SW. I have already given a link to the southbridge datasheet clearly showing how it works. No general-use soundcard is using any software timer for generating bit clock.

I havn't seen anybody in any forum, who was able to proof what's going on inside a PC based digital chain. Nobody is covering the whole story.
The majority of the so called "specialists" are usually picking this or that argument but really never present a holistic view.

??

I think the "Trial and Error" method following a certain direction - something like - "Less is More" - is IMO for the time being a nice approach.

I agree that less is more. How does this correlate with your push for real-time extensions, low latencies for playback (both keeping kernel/CPU pretty busy), extra layers of software (ecasound) for pure calling alsa-lib API? In fact, it is the exact opposite.

Continuing this argument makes no sense. Just please keep adding "in my opinion" to your resolute statements.