Linux Audio the way to go!?

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
Hi,
I wasn't able to hear a difference between this ecasound player and my normal mpd -> alsa playback scheme. Perhaps a *very* slight better bass reproduction. This with an ancient ATX-board based PC and an PCI-Soundcard from RME (Digi96 8 PST) for analog out and a slightly dated kernel (2.6.24-23-rt). Yes, I will try an battery fired mini-PC and external DAC someday...

Rüdiger
 
Hi,
I wasn't able to hear a difference between this ecasound player and my normal mpd -> alsa playback scheme. Perhaps a *very* slight better bass reproduction. This with an ancient ATX-board based PC and an PCI-Soundcard from RME (Digi96 8 PST) for analog out and a slightly dated kernel (2.6.24-23-rt). Yes, I will try an battery fired mini-PC and external DAC someday...

Rüdiger

Hi Rüdiger.

Good to see that you got your rt-permissions settled. ;)

Some comments:

1. You just tried the alias, not the entire WIKI ( see prerequistes).
One day you should upgrade your system. ;)
2. I guess you didn't run in recovery mode either.
3. The low-end improvements are typically what people realize first.
It gets better the lower the distortions are. The upper end improves
usually in a similar way. Makes sense, doesn't it.
The upper-end improvements do have a harder time to get through the
other bottlenecks in the chain.

THX for now.
 
There is no reason to hear a difference, unless you spun down your HDD while playing to keep the power lines cleaner. In both cases the PCI card receives the same data on time.

:D I knew it was coming. :D

There are endless reasons. Do you want me to repeat them again? ;)

I thought that maybe my RME would be immune. It's not.

Meanwhile you'll find a huge community with quite resolving systems on AA confirming all this. Most of them doesn't have the hindering IT background
to get biased. They just play something and listen to the result.

Even some commercial SW providers realized, that there is more behind "we all use the same API -- sound can't be different".
You're just leaving out in your judgement a lot of obvious side effects by thinking that narrow minded.

I'll soon put some stuff - the way I look at it - in the Wiki.

Anyhow - the best solution is to stay out of a PC! But that's not always an option.

Cheers
 
1. You just tried the alias, not the entire WIKI ( see prerequistes).

I don't know what you mean. The wiki is empty apart from that player guide.

I installed the very latest alsa, mpd and ecasound software some months ago and left it with that.

Honestly, I don't intend to setup a system that needs updating every two weeks or so. Once I'm done, it shall work as it is, or as long as I don't need or want additional functionality (aka room correction or something like that).

Anyway, your input is very much appreciated and I learned something so far already.

Rüdiger
 
I don't know what you mean. The wiki is empty apart from that player guide.

I installed the very latest alsa, mpd and ecasound software some months ago and left it with that.

Honestly, I don't intend to setup a system that needs updating every two weeks or so. Once I'm done, it shall work as it is, or as long as I don't need or want additional functionality (aka room correction or something like that).

Anyway, your input is very much appreciated and I learned something so far already.

Rüdiger

Rüdiger.

Don't take my points wrong. Don't regard it as critism.
I am just saying there is no way, we can compare your setup with the one I described in the Wiki. I am referring to that particular Commandline player Wiki article only.

You are using a pretty outdated kernel. A lot has changed recently.
In line with your pretty old Ubuntu revision are coming pretty old
libraries and applications. E.g. No idea what ecasound revision you
are using, if you install it from that old repo.
Just installing a new Alsa only won't be sufficiant. You would at least need to compile a new ecasound (2.7.1) on that new Alsa.

There'll be 100dreds of potential bottlenecks, even a single problem or a single parameter shift "might" be sufficient, to get you away from the result I'm talking about.
For example as we've seen last night. You had that crucial rtprio parameter wrong. With this setting you never really were able to apply rt
priorities to any process since two years - assuming you did this config during the installation process of your 2.6.24-rt kernel. MPD on it's own wouldn't notice that rt-kernel anyhow - it is not optimised for rt operation. You could have run any other kernel without noticing any difference.

What you could do now for a valid comparison, you could pipe one MPD output to a new ecasound. This way you can very simple check the differences. This of course requires the newest MPD - what you need to compile manually. Your old MPD wouldn't support output to pipe.

When it comes to updating a system, I really prefer to run the latest stuff.
If I compare my Mint Helena to anything else I had before - I must say it is ways better. By doing this you'll always face much less incompatbilties with well maintained applications - such as ecasound.

You must be two years back by now - don't you?

It takes me two hours to setup a complete new system, with my latest configurations/customizations.
To be able to do that I need to write down all my customizations I've done over time. ( Many of these infos you'll find in the Wiki.) I do understand that if you don't do that, you'll have a hard time to step up your system regularly.

Anyhow - for me it was sufficient that you told us to experience a slightly tighter bass now. Looks like we're heading into the right direction. ;)

And Thx again for checking out the Wiki at least partially. It seems to be functionally working so far.

Cheers
 
Rüdiger.
It takes me two hours to setup a complete new system, with my latest configurations/customizations...

Two hours, for someone who knows what he's doing and has copious notes.

Does anyone else see anything wrong with this?

Look, I make my living working with Linux every day, so I am not at all intimidated by compiling something from source, tweaking configuration settings, etc., but I have found the state of Linux audio applications to be completely frustrating. To the point that I consider it a waste of my time to mess with it beyond a fairly "stock" setup for a given distro. Even then, some of those are broken "out of the box".
Until this mess is fixed, Linux will never enjoy any kind of penetration into this space. The only reason it lives on my "entertainment center" PC is because it's capabilities with other types of multimedia formats.

Just sayin'...
 
soundcheck, do you really consider

I wasn't able to hear a difference between this ecasound player and my normal mpd -> alsa playback scheme. Perhaps a *very* slight better bass reproduction.

the basis for:

Anyhow - for me it was sufficient that you told us to experience a slightly tighter bass now. Looks like we're heading into the right direction. ;)


New kernel will not sound different. New alsa drivers will not sound different provided they did not make any changes e.g. in RME DSP firmware which I doubt. New alsa-lib will not sound different. New ecasound will not sound different provided the setup is bit-perfect.

An older installation will sound just the same as a new one, provided the chain is bit-perfect of which there is no reason it should not be.

Please stop confusing beginners.
 
Hi,
now, I have no intentions to harshen the discussion! My english is not that good, so I might sound harsh sometimes even if I don't intend it, especially if I'm fiddeling with something...

First, I should make it clear, the sound as of now is by no means bad! It sounds quite a bit better than my last CD-Player (Sony ES-Series).

I admit I have a hard time to believe that different players that don't do any filtering or such things and playing into alsa make a different sound. But then, there *are* differences between CDP's and computers, and, who knows...

My mpd version is 0.15~git and has:

Supported outputs:

shout null fifo alsa ao oss pulse jack httpd

alsa is 1.0.20

Right now, I indeed have a problem, that is I can't capture via the rme card, there simply is nothing in alsamixer's capture mode with this card. So, if I don't find a solution, I have to try to update.


I agree that linux audio is hard to handle, hence my idea to have a very basic system some day with nothing more than alsa, mpd, cdparanoia and ethernet (and it's dependencies) as long as another player doesn't sound better to me.

Klaus, no offence meant or taken, thanks for your efforts.

Rüdiger
 
Two hours, for someone who knows what he's doing and has copious notes.

Does anyone else see anything wrong with this?

Look, I make my living working with Linux every day, so I am not at all intimidated by compiling something from source, tweaking configuration settings, etc., but I have found the state of Linux audio applications to be completely frustrating. To the point that I consider it a waste of my time to mess with it beyond a fairly "stock" setup for a given distro. Even then, some of those are broken "out of the box".
Until this mess is fixed, Linux will never enjoy any kind of penetration into this space. The only reason it lives on my "entertainment center" PC is because it's capabilities with other types of multimedia formats.

Just sayin'...

Just sayin' . Everybody is allowed to express his own opinion.

How about trying Computer Audiophile Forum and switching to OSX?
Much less hazzle. Get yourself a MAC install iTunes and Pure Music and you're done. Just lean back and enjoy - makes your live much easier.
If you need more advise let me know? ;)

Or as I said earlier. Hook yourself up to a tweaked Squeezebox and you could stay out of this PC audio discussion completely.

We are at DIY Audio over here - Linux IMO matches 100% a typical DIY-Audio inmate profile. Obviously the world of PC hasn't arrived at DIY-Audio yet. You need to look up Audio Asylum or CA for it!
Folks -- try to figure out how many threads you'll find over here talking either about PC HW or SW optimizations. 1,2 or 3?

Most of the forum inmates don't mind to spent 100s of hours on discussing and fiddling around with capacitors and opamps of choice. A PC though still is considered a black box and according to Phofman it for sure is black box and it'll stay this way because he read the code. The point is neither he nor anybody else has a clue about the physical and/or logical implications (timing variations resp. jitter extra noise, EMI, etc.) of anything ongoing inside the PC and I doubt that Phofman looked very much deeper then the Alsa layer - correct me if I am wrong. Did you ever measure timing variations and drifting clocks or noise levels, power spikes and power drops inside the PC and all this related to scheduling variances, different load conditions etc. and finally how much of these arrive at the DAC/Soundcard? You don't have to answer that.

What's being proved - reported by a lot of people: The less is going on on the system and the less physical or logical impact you'll have on the stream the better the result will get on the majority of soundcards.

Again @phofman - it is not about bit transparency and not about your last buffer in the chain - not in this discussion. One day you'll might understand it.

Perhaps one day I'll understand or better learn what's causing the changes.

Cheers
 
Last edited:
Just sayin' . Everybody is allowed to express his own opinion.

How about trying Computer Audiophile Forum and switching to OSX?
Much less hazzle. Get yourself a MAC install iTunes and Pure Music and you're done. Just lean back and enjoy - makes your live much easier.
If you need more advise let me know? ;)

Your condescension is... misguided.

"iTunes"? Really? Please... I have built my own speakers since 1975. I've been building my own amps (both sand and valve) for almost two years. So please spare me the veiled insults about listening to .mp3's. OK?

And again, I've been digging around in the guts of Linux for as long as there's been a Linux. So I believe my DIY credentials are up to even your arrogant standard, sir. The difference I point out is that a given speaker or amp component can be expected to do what it's specs say it will. The fun, of course, comes in the artful combination of all those bits. Sometimes the results are magical, sometimes not so much, but always a result. The state of Linux audio components, however, seems to much more a case of dumb luck when it works out right, once you leave the confines of a well debugged mainstream distro. This or that driver or program, may or may not, depending on the version(s) involved, work in a given configuration. Yes, yes, I understand what dependencies are and know how to go about resolving conflicts. My point is, why should I have to? Among the many wonderful things that can be built upon Linux, audio, for whatever reason, seems to have suffered inordinately from a lack of convention, documentation, and standards. In other words, the quality control blows. Having to chase down a magic recipe through various forums and bug trackers is not how it should be.
 
Sorry, I don't really see all of this problems. IME, with most modern distros sound works pretty well out of the box. Admittedly, the general adoption of "PulseAudio" in most recent distributions was a rather awkward move for "hi-end" audio (at least with the current limitations of pulseaudio). Yet it is usually not too hard to get rid of it, or one may still choose a distribution which does not use it by default. Apart from that, if your hardware is well supported I don't see what's the problem.

Of course, doing "strange" (unusual/advanced) things such as complex audio routing with real-time processing and/or implementing tweaks such as the ones proposed by soundcheck or others (I'm not goin' to argue whether they do make sense or not here) is a whole different story.

But you can't blame Linux (or ALSA) for that. Doing the same things on other systems is usually even harder, or not at all possible. In most cases, you can't go beyond what have been foreseen (and/or allowed) by the OS/drivers/software producers.

So what?

If you just want simple (digital or analogue) audio out, just install a recent distribution and use it as-is. IME, it usually sounds much better than an untweaked windoze anyway. And it's not any harder to install or use.

If you want to try tweaks & hacks, you can't complain about gettin' your hands dirty, can you?
 
If you want to try tweaks & hacks, you can't complain about gettin' your hands dirty, can you?

I 100% agree, here. And I also agree that out of the box Linux sounds "pretty good" as you say. However - "pretty good" is not enough for me.
A buffalo DAC sounds also "pretty good" out of the box....the thing is- many people consider it not good enough and do something about it.

Linux has its problems and limitations. The other OSs do also have certain limitations though.

I still consider the "soundlayer" under Linux - the way it's handled, maintained, the number and features and soundcards supported, the timely availability of drivers and its integration into the OSs a major limitation.
No idea who'd be able to get this under control. If I look at my RME card.
I consider it a major disaster how to handle that card. And this card is supposed to be one of the best professional supported cards under Linux.

With the proprietary GPU drivers of e.g. AMD and NVIDIA - IMO only with these - Linux becomes competitive at least on the graphics side.

Linux would be much better off to introduce proprietary drivers on the audio side too. This for sure would resolve a lot of issues.

Cheers
 
Linux would be much better off to introduce proprietary drivers on the audio side too. This for sure would resolve a lot of issues.

How would a closed-source kernel driver solve the clunky user-space tools for controlling all the numerous controls of the functionally-complete open source RME driver? In fact all you need is an open source GUI tool for the existing open source driver.

You can talk to Creative or Lynx if they devote the resources needed to keep their respective binary driver compliant with current kernels, just as Nvidia and ATI do. Good luck. Linux itself will not introduce anything as it is just a piece of source code, it is the manufacturers who would have to provide a binary driver and open source compatibility layer, just as in the graphics subsystem. And noone has ever prevented them from doing so.
 
Your condescension is... misguided.

"iTunes"? Really? Please... I have built my own speakers since 1975. I've been building my own amps (both sand and valve) for almost two years. So please spare me the veiled insults about listening to .mp3's. OK?

"Misguided" - I don't think so. It was a serious advise.

As you might know OSX is based on Unix. The OSX Core Audio sound layer and driver support is similar to the Windows level and is better organized/implemented than Alsa.

Generations of PRO-Audio musicians are using very successfully OSX.
Recently I read remarks of people prefering Jack on OSX over Linux. So even the realtime kernel and Jack is no longer an argument to stay with Linux in this area as it seems.

Regarding iTunes and mp3s.

You misunderstood that one again. ( sorry for my poor English or my ability to express myself properly)

There is a new app called Pure Music, which is actually a plug-in to iTunes under OSX.

Pure Music incorporates many of the tweaks I'm bringing up over here since I started the thread 3 years ago.
Not just a small number of people reporting "Best sound from an OSX" ever. (Of course non of them have talked to phofman - I mean OSX has always been bitperfect - so how can that be the case?)
Pure Music is passing by the iTunes sound engine and in the latest versions it even gets coreaudio out of the way as much as possible ( similar to routing Linux to hw from what I understood.). It runs the tracks 100% from RAM, does full 64bit processing if volume control is wanted .....

Having built speakers from 1975, won't prevent you from not being up2date.
Being up2date on all fronts I consider almost impossible for anybody.

So - I don't consider this serious advise an arrogant response to your pretty negative attitude about Linux in your earlier response . I just intended to show you ( and others reading all this) a way out of the existing limitations
of a Linux system.


And again, I've been digging around in the guts of Linux for as long as there's been a Linux. So I believe my DIY credentials are up to even your arrogant standard, sir.

"Arrogance". No Sir - I do have a problem with people claiming they know everything about Linux for about 20 or moreyears, but won't look left or right.
The whole discussions are about HW and SW and not Alsa only - we're talking about a very complex system here. If you look at phofmans answers, he always refers to Alsa only. What I really miss, is a bit flexibility.

Cics of AA is the only one I am aware off, who brought HW and SW and it's impact to each other together and even tried to explain it. Of course he failed explaining or proving it. At least there is a huge crowd following his advise. His solution matches on large portions exactly my tweaks and recommendations for a Linux environment.
Cics just runs the wrong OS, which puts him against a wall at the stage he currently is.

I need to get back to my rather constructive work on the Wiki. Too much philosophy talk for my taste recently.

When I offer people to try my proposed tweaks, they can do it or leave it.
It's up to them. I said that before. The results I describe I do hear on my system. If anybody is interested in a listening session - you're invited.


Cheers
 
How would a closed-source kernel driver solve the clunky user-space tools for controlling all the numerous controls of the functionally-complete open source RME driver? In fact all you need is an open source GUI tool for the existing open source driver.

You can talk to Creative or Lynx if they devote the resources needed to keep their respective binary driver compliant with current kernels, just as Nvidia and ATI do. Good luck. Linux itself will not introduce anything as it is just a piece of source code, it is the manufacturers who would have to provide a binary driver and open source compatibility layer, just as in the graphics subsystem. And noone has ever prevented them from doing so.

Hi phofman.

Closed source software protects the assets of companies. If you want to get them involved, you need to provide them with a base to protect these assets.
Companies will be interested to deliver equal quality on all systems, if they get themselves involved.

I don't think very many users would have a problem with this.


If I look at my RME 9632. The mixer and config apps are not comparable to the ones you'll find under Windows. They lack quite some features etc. Nobody maintains them since years.
You need quite complicated ( for a normal user almost impossible to handle) .asoundrc configs to be able to get the card under control - to make it default device. etc.)
Alsamixer just allows for some config settings. You need amixer to control the cards other mixer features (mixing/gain etc.) not covered by alsamixer.
All this is even me ( advanced Linux user) challenging quite heavily.
People recommend to use Jack to be able to use all the channels properly.
The card is not manageable via Gnome-mixer etc. How do I implemt an autostart feature without using the HDSPmixer apps? How do I get amixer and HDSPmixer in sync?

Does all this sound like a well done soundcard implementation? Do you think there is hope for improvements?

If you ask me - No - This I consider good old Linux hacker land. Of course you'll get it working -- with a bit more than average involvement and with a bit more knowledge then average -- and with a bit of hacker spirit. The overall operation will remain a compromise though.

I am sure that if the SW around that card would be managed by RME, things would look slightly different.

Outlook:

We'll soon see a shift in the Linux world anyhow. The talks about commercial SW ( closed source) under Linux are well on its way. I read somewhere that there are plans to introduce a commercial function into the new Ubuntu App-Store. This means soon we'll see much more commercial and non-commercial closed source SW on a Linux system.

Of course this is not in line with the original Linux spirit. There'll be many distros of course, that will not follow that track. I am sure there'll be ways to meet all users demands.
It'll be up to the user what to go for. You know - even I rather pay a couple of bugs for a "fully" functional software driver and reasonable control software embedded into an windows manager - then living with a compromise forever.

Cheers.
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.