Audiophile Linux software - Page 5

Except that you can. With ASIO4ALL you can handily bypass the Windows mixer. And applications can use the new audio APIs in Windows Vista to request exclusive use of a device which also bypasses the Windows mixer. And there are other kludgy ways to get around the kmixer if you don't have Vista.

And mixing by itself doesn't degrade the sound terribly much - I bet most would be hard pressed to detect the difference in a double blind test.

And BTW, the Windows HAL is a different beast than the audio device drivers that talk to audio devices (but that's probably getting too deep).

Well, that's a bit of a contentious statement. (And yes, I run both Windows and Linux and have written software professionally for both.)

Windows has 32 priority levels underneath, 16 of which are kind-of reserved. Yes, you can only specify SIX different levels through the UI, but you can specify all 16 (or 32) programmatically. And Windows does a fairly decent job under most circumstances of dynamically modifying priority levels in response to user input so that UIs remain responsive without requiring the app presenting the UI to remain at a permanently high priority. Yes, there are situations where it doesn't do what you want - but the same applies to Linux (I say that after waiting 20s for my MythTV box to skip ahead 30s during video playback last night.)

It depends which process is generating that signal, because that process has to feed data to ALSA at a reasonable rate. Renicing that process would indeed have an effect.

...which is functionally equivalent to using ASIO4ALL or Vista APIs to direct audio in Windows to a device in exclusive mode.

And if you don't do that, you have a mixer enabled - just like Windows!

It's simply not true that the architecture of the OS is what makes the difference - it's the configuration of the audio stack and apps!

(...which is true only if you have ALSA. There are other options - although becoming less common).

I run MythTV on Ubuntu with my audio server, but ASIO4ALL had fewer issues (not zero!) when setting it up on Windows than ALSA had on Linux. Admittedly I have more than one device on my server, but that's true on my Windows boxes too once I plug in my USB DAC.

You can certainly get both OSes to do what you want them to do.

My post was just for someone looking for this info can find it useful, and tried not to be too technical at all. If it had some incorrect info, I apologize. Given that I still think architecture makes a difference.

That's right, and that's one of the reason you'd use ASIO.


Yes I agree by itself its not. But its the win kmixer w/ it's inferior algorithm that degrades the sound, not the act of mixing it. Otherwise there are no need for ASIO.


Correct me if I'm wrong, but the Hardware Abstraction Layer is the API that calls the audio device driver, and beside the team in Redmond who design the audio portion of that, no one else know the true performance of that piece of layer. ALSA, OTOH you can dl the source in 30 mins and trace the whole signal path if up for it.


I was incorrect in pointing out the "user priorities" in the first place as it does not matter in audio anyway. (And I'm forturnate enough to only needed to touch the spaghetti API MFC for couple projects.)

So lets focus on the audio signal path. The 16 priority are your APPLICATION's priority, once it's handed to ASIO (which you can set its own priority, thank god), it gives to HAL->drive->device. Now if someone beside the guys from Redmond can tell us how the kernel's scheduler instruct priorities of the audio stream through this part of the pipe without a lawsuit, we can then know how good it is.

OTOH, I can tell you the current 2.6 kernel is using the "complete-fair scheduler"(creative isn't it...) that is assigning the priorities between the ALSA and the device drivers (it does go through the kernel), and anyone+world+dogs can find out how it assign the priorities regarding the audio streaming from the app to the ALSA, and from the ALSA to the driver, pretty much the whole pipeline.

(As for MythTV, I totally agree the user app stacks of linux is still short of windows, but that's not the issue here, plus players can/will only becomes better.)


The "process" you said. I believe you mean the app or thread. 95% of the code (say amarok) running in the memory have absolutely nothing to doing with feeding data to ALSA, they're busy showing GUI, spawning processes under this same thread to read/write the disk, loading codecs. etc etc. If this is a pure audio server, then that's no problem, like previous post from LnxPrgr3 said, just get the audio earlier. Most users however got other things running, and my post just wanted to point out to others that they need to understand how players don't actually play out the sound, it's the ALSA that play the sound. And sure I'd nice it -11 if I'm building audio server. This is a difference concept than in windows, where u boost the heck out of anything that touches the signal path.


Yes again you're right, the dmixer. But like the creators of ASIO and your post said, the mixing itself does not degrade the sound. It's the method/code they use that degrades it. And I'll take the dmixer code anyone can see/test, and has been through scrutiny any day.

True. You can achieve the same goal with both, and I never said windows cannot anywhere.

But when I read from other people's posts, seems they were applying windows apps notion in Linux (boosting priorities, inserting extra layers of API/app to get extra performance), which to me does not work the same. I mean some posts still asking ASIO in Linux, because they never understand why ASIO exist in the first place (a bug fix, bypass). To me Linux simply is more straight forward, overall less cluttered, more scrutinized, thus no need for all the tweaks/hacks in windows. Read first line of my post, that was my post's only intention :"From this thread it seems alot of people misunderstand the architecture between windows and Linux." and the last "I believe Linux gives you the shortest path, with highest priority handling of signal in audio without much tweaking"


To me in Linux, you install the OS, config your ALSA, disable the dmixer,
BAM....you are done, and use any players you like, and get the best sound possible.

And if someone telling me architecture does not make a difference in term of...anything...that happens in a computer. Well, that's fine too, I'll forget whatever I learned from college CS301_computer_architecture class, and pick the one that has spinoffs in NASA, NSA, real-time OS, cellphones, medical devices, and carrier-grade routers over a blue screen (did they change the color in vista?)....

Yes, sorry if I came across as a bit peeved or pedantic - was a bit pushed for time when I posted last and hurried out a few points to note.

IIRC the problems with the kmixer are because it resamples everything (and not as well as can be achieved with careful work), not because it mixes. (And I can't recall whether that situation improves with the Vista mixer either - haven't needed to know yet, but IIRC Microsoft claims to have improved it).

The Windows HAL is the piece that abstracts the underlying platform hardware for the benefit of the kernel. This is not the same as abstracting the underlying I/O devices (such as sound cards and DACs). Typically the HAL abstracts CPU differences, I/O controller differences, interrupt controller differences, memory manager differences, etc. across supported platforms. An audio driver might use the Windows I/O subsystem to send data (via the abstractions provided by the HAL) to an I/O controller in order to communicate over a bus to a hardware device.

I'm not particularly knocking ALSA (nor particularly praising Windows audio). ALSA can be a PITA to configure, compatibility with different hardware can be spotty, it stops working mysteriously and then starts again for no good reason, and it often doesn't give you any hints why it's not working as you think it should - but it's highly configurable and you have a lot of control over how it does its thing once you persuade it. It's quite a nice model. And we know a fair bit about the merits and demerits of Windows audio too but it can be made plenty good enough.

Argh! Please don't remind me. MFC was an ugly abomination that never should have seen the light of day. Fortunately I largely managed to avoid using it in anger. Back to the topic...

ASIO is a user-mode app - and I believe (without checking, so could easily be wrong) that it relies on a user-mode driver (as most Windows USB drivers are). So the priorities given to the ASIO process are fairly important to make sure the data keeps flowing - the same as on Linux.

IIRC once data gets into the I/O subsystem priorities are handled by the kernel in ways that are reasonably well defined (if you want to read a bunch of technical books & documentation), but I've never had to write a kernel driver so I'm no expert there. You might try looking for Sysinternals and books written by their principals (IIRC Mark Russinovich and others) - they're pretty hardcore experts on Windows internals.

But in the end for most people the point is not the data paths and priorities, but how well it works in practice - does it reliably produce good quality audio output without buffer under-runs or unwanted resampling or other distortions/artifacts?

I meant exactly what I said. Last time I looked you "nice" a process under Unix, not a thread (and you do the same under Windows if you use the Task Manager to change process priorities) - although I haven't looked recently to see if there's now a similar thread level operation.

And since the process is the unit of external priority modification, then it matters that there is some process that feeds data to ALSA (and whether or not it also embodies a UI does not really matter). That process needs to be able to keep feeding data without buffer underruns etc.

...which is a good point, but incomplete. ALSA plays the sound, but some OTHER process feeds the sound data to ALSA, and some (potentially different again) process reads that data from disk or CD or network, and those tasks may involve still other processes, and they all have to work well enough for the system to produce glitch-free audio.

Note that splitting the communications to ALSA from the UI also leads to players that can get woefully out of synch (several seconds) with the audio that's playing, which is a different kind of PITA.

True, there was some confusion, but boosting priorities may sometimes make sense - if you have a problem, and if you do it to the right process(es), and if that addresses the root cause. But you are also right in that it's better to take complexity out of the ALSA signal path in the first place and see if that solves your problem before you mess with priorities.

No need to manufacture strawmen now...

Which is fine for you, but if I wanted a music player my wife could maintain without needing to call me if and when something goes wrong (typically when I happen to be away on an extremely busy business trip), I wouldn't use Linux. It has a lot of things going for it, but "easy to configure" and "easy to maintain" are not two of them. It's improving all the time but it still has some way to go...and Windows can be made to play audio quite well enough for these use cases today.

Sorry, meant to add a response to this comment too. I reiterate that it took me several weeks of on-again off-again fiddling to get ALSA sorted out on my MythTV/audio server box (some of which was spent figuring out that I was never going to get the onboard Intel HDA to stop quietly distorting some passages, but I went through half a dozen other issues). And I kind-of know what I'm doing compared to most users. I'd probably get it going three times as fast now that I know some of the issues to watch out for.

OTOH I got ASIO4ALL working in its final config in a couple of hours (including trying various tests and options) on my Windows boxes and it's been that way ever since. Sure, Winamp can still silently lose the ALSA sync or communications channel and need a restart at times...but then Amarok locks up or outright crashes at times too.

Cheers,
Mazz.

Would you mind clarifying that for the benefit of us noobs in the audience?

I use Clementine to play my .FLAC files. I use RipperX or Sound Juicer to rip my CDs and convert them to .FLAC files. I am using Ubuntu 11.10 64 bit and I plan to upgrade to 12.04 64 bit LTS and perhaps I will stick with that version for the next two years. I have no problem with the default audio as it plays my music just fine and I can listen to my music. I don't want to install WINE just so that I can use EAC and Foobar2000 as I find no differences in sound quality when I was using Windows 7 Ultimate 64 bit on my work computer at the university. Clementine is the best music player for Linux and it is in the Ubuntu Software Center if you have Ubuntu 11.10 64 bit. It will be in Ubuntu 12.04 64 bit LTS if you are willing to try the current Alpha or Beta versions on a test machine or a virtual machine.

 

 

Even though ALSA upsamples everything to 32/48000 in software?

 

 

 

Better than the lightweight DeaDBeef a.k.a the foobar2000 of Linux?

Edited by adamlau - 2/5/12 at 11:19pm

 

Using the hw: devices avoids that. It is basically like using WASAPI under Windows.

I use two sound cards, an old SB Live (emu10k1) as card 0, and a newer Asus Xonar as card 1. The emu10k1 is very well supported under Linux, and can mix and resample in hardware (among other useful features), so I could get rid of all software mixing and resampling and the related problems and annoyances. For music playback, I can use the Xonar (hw:1,0), and since it is not the default device, it is left alone by the system. I guess a similar approach would work with onboard audio as card 0, using software mixing, and a real sound card as hw:1,0 for applications that demand sound quality. The disadvantage is that some badly written software (e.g. Flash Player) will never use anything other than the default device.

 

Edited by stv014 - 2/6/12 at 1:35am

OSS can be purchased which I am thinking about doing so, but it comes with a limited 1 year license for the free version so that I can try it out. I have a high end audiophile CD player with a separate DAC and another box with a USB 2.0 input from the same manufacturer and I am getting terrific sound quality when I play my .FLAC files at home. I have a HeadRoom Total BitHead for usage when I am on the go and I have one of the top three universal and custom IEMs on the market. I don't complain about the sound quality of ALSA. I might give OSS a try though.

https://help.ubuntu.com/community/OpenSound

I have switch to the Linux for good a year ago.

 

Foobar2000 is 100% workable via Wine - supports embedded cue in flac, vw, ape with ability to edit this cue.

qmmp is quite good, and support embedded cue in flac, vw, ape.

Audiacious is also OK, but have tendency to hang up with one of my USB to S/PDIF converter.