I'm not sure why you folks are arguing about linux distros? Split your OS from your data, then backup the OS, if it gets corrupted just restore from a backup. It's unlikely that you will even have any "data" on these devices.
If you really screw it up and need to rescue things then you can get into limited single user mode by altering the kernel command line or if you prefer then boot from some rescue CD, etc.
I really don't see that starting with Ubuntu and taking stuff out is such a bad idea, especially if you are loosing all the X stuff (ie you can be pretty brutal and unsubtle about turning stuff off). I don't know Voyager, but no doubt it's also a bad starting point.
Note, I'm building embedded builds from source, these start from a couple of MB and go from there. From that point of view any of these off the shelf distros look pretty bloated! As such if you want to build it in a hurry and you have the disk space then just start with any distro you are famliar with and go for it!
If you really screw it up and need to rescue things then you can get into limited single user mode by altering the kernel command line or if you prefer then boot from some rescue CD, etc.
I really don't see that starting with Ubuntu and taking stuff out is such a bad idea, especially if you are loosing all the X stuff (ie you can be pretty brutal and unsubtle about turning stuff off). I don't know Voyager, but no doubt it's also a bad starting point.
Note, I'm building embedded builds from source, these start from a couple of MB and go from there. From that point of view any of these off the shelf distros look pretty bloated! As such if you want to build it in a hurry and you have the disk space then just start with any distro you are famliar with and go for it!
Hello guys!
even if am a linux user since 2003 I still get confused when it comes to audio. I have to say that I never understood how audio works in most platforms... linux documentation is not less confusing than its competitors' documentation. Having said that I went through these interesting post, but I am still missing the fundamentals... I hope somebody will help! Before to ask help, let me just tell you my experience.
I recently bought an ESI Juli@ card from which I get the SPDIF signal which then goes into a Gigaworks DAC with the CS8421 upsampler and output trasformer (the best DAC I ever had). Up to this moment I played files via Win 7 using several softwares. But I would really like to play via linux with which I am more familiar.
The best option was to use CPlay (which is not very nice to use). I also tried several combinations of upsampling via PC or DAC. The best thing was to upsample to 48KHz before to send the signal to the DAC upsampler. If I bypass the DAC's upsampler and I send the signal upsampled by the PC I loose some low level detail and the sound is smoother too... I guess these guys at CS really know how to upsample! Since CPlay uses SoX as the underlying resampler I had a look to what SOX does to the signal spectral domain... when the upsampling ratio increases SOX smooth the high a bit... I guess this is because it uses some sort of moving average (over)fitting which of course will act as low-pass! Anyway the CPlay with ASIO drivers and 48KHz resampling + DAC rockets great... I am now really enjoying the huge dynamic range that my active system is capable of!
Having said all that, I would like to be pointed to a good source to start with. My ESI Juli@ has alsa support, but I really don't know how to configure alsa parameters (sampling rate, possibly resampling etc). I am also confused about palyers. On my office computer I use EXAILE which is simple and effective, does it have any problem when it comes to hiend audio?
I hope somebody can help me!
K
even if am a linux user since 2003 I still get confused when it comes to audio. I have to say that I never understood how audio works in most platforms... linux documentation is not less confusing than its competitors' documentation. Having said that I went through these interesting post, but I am still missing the fundamentals... I hope somebody will help! Before to ask help, let me just tell you my experience.
I recently bought an ESI Juli@ card from which I get the SPDIF signal which then goes into a Gigaworks DAC with the CS8421 upsampler and output trasformer (the best DAC I ever had). Up to this moment I played files via Win 7 using several softwares. But I would really like to play via linux with which I am more familiar.
The best option was to use CPlay (which is not very nice to use). I also tried several combinations of upsampling via PC or DAC. The best thing was to upsample to 48KHz before to send the signal to the DAC upsampler. If I bypass the DAC's upsampler and I send the signal upsampled by the PC I loose some low level detail and the sound is smoother too... I guess these guys at CS really know how to upsample! Since CPlay uses SoX as the underlying resampler I had a look to what SOX does to the signal spectral domain... when the upsampling ratio increases SOX smooth the high a bit... I guess this is because it uses some sort of moving average (over)fitting which of course will act as low-pass! Anyway the CPlay with ASIO drivers and 48KHz resampling + DAC rockets great... I am now really enjoying the huge dynamic range that my active system is capable of!
Having said all that, I would like to be pointed to a good source to start with. My ESI Juli@ has alsa support, but I really don't know how to configure alsa parameters (sampling rate, possibly resampling etc). I am also confused about palyers. On my office computer I use EXAILE which is simple and effective, does it have any problem when it comes to hiend audio?
I hope somebody can help me!
K
Last edited:
You are touching a lot of different aspects.
To follow the CPLAY/CMP2 logic on a Linux system you need to follow "my" logic on a Linux system. ( Not many people over here ever tried that approach, or would agree to it - many of the active crowd over here puts it into the voodoo corner)
Outline of my solution:
1. You need an rt-kernel
2. You need to shutdown as many processes as possible - best to boot into recovery mode - preferably on a headless client.
3. Copy your audio data to /dev/shm (ramdisk) before playback
4. Use ecasound as playback engine
5. You can use all HW and Bios optimizations as proposed by Cics
When using Sox under Linux make sure that it is not doing automatic dithering. Offline processing is prefable over realtime processing.
You won't find an app under Linux which focuses on "Best Sound from a Linux system" and at the same time is delivering a nice GUI.
VLC is getting better and better though - it offers a lot of optimizations (sse) and a realtime-kernel support.
I recently switched to a Linux based Squeezebox Touch feeding a Sabre DAC connected to a Linux based server. I am more then happy with this solution (after applying some modifications).
Cheers
I hope this won't cause a disproportionate response, but my opinion is that Soundcheck's advice is not incorrect, but largely voodoo and you almost certainly don't need to do all of this.
RT kernels are all about getting the latency between switching two tasks (to simulate having multiple processors) to be of very low granularity. In fact I think you can usually get away with a normal kernel for nearly all tasks, especially if you tweak your applications a bit
I'm not sure ecasound is special in any way. I'm sure it's also fine though? People get excited about audio daemons but they largely just pass through data unaltered if you configure them correctly. Nearly all apps you might want to use would also work very happily with no audio mixer daemon though and you could talk to Alsa directly?
Alsa also has a very high quality resampler built-in (libsamplerate) - however, note libsamplerate has three modes, I guess read the docs to be sure you are using highest quality. This is largely of similar quality to the new sox resampler (but be aware that old sox versions from a few years ago only had a horrible resampler - the new version is superb quality, the old is duff...)
At the end of the day if you lock your soundcard to the rate you feel it performs best (eg 48Khz), then let Alsa resample everything to that for you, it will do it in excellent quality.
Secondly, although folks whitter on about doing things offline, etc - the computer will internally read quite large chunks of audio data, process these large chunks and then feed these large chunks into to the soundcard where they will be dealt with by a separate "processor" that is completely separate to the main computer. This seems badly understood, but literally the sound card will be fed buffers of say several thousand samples (so between tens and hundreds of millisecs of audio) and left to get on with pumping them out of the DAC however it sees fit
Now we can imagine that the computer can influence the DAC quality, but that influence will be limited to say drawing a bunch of power, causing the PCI powerlines to sag, in turn influencing the DAC... Seems like a bit of a stretch to me? (And if it is an issue then you would be advised to mod your card first rather than **** around in software...)
Just as a stake in the ground, I use Mythtv as my media player, an RME 9632 as the 6 channel DAC and audio is output via the Jack soundserver purely because it allows me to hook in Brutefir to mangle the audio. Brutefir is used to apply some long FIR filters (calculated using DRC) and also to apply crossovers between drivers (I have a 4.2 surround system, ie stereo IB bass and 4 full range speakers on each corner). I run my system at 44Khz so CDs are not resampled, but DVD/TV is resampled from 48Khz down to 44Khz using libsamplerate (myth does this internally, but you could use alsa to do the same). I usually run the system at around 10ms latency, but it works fine at 5ms latency and somewhat below (this is while say playing a 1080P blueray, resampling audio down to 44Khz, convolving 6 channels of audio with massive length FIR filters, all using a non RT kernel and yet it never misses filling an audio buffer)
I doubt the above will suit your needs though, so the question remains what audio player... Hmm, I guess try all the usual culprits such as mplayer, xine, XBMC, mythtv and a google search will turn up a ton of other less well known but very interesting options - see what suits you best? I think the only thing you are likely to find is that several of these players have resamplers of variable quality built-in and so you may need to watch the configuration a little to ensure you don't use the internal resampler, but instead the Alsa resampler (or at least understand which one is being used and the compromises as a result)
Resamplers are poorly understood, but suffice to say there are no "moving averages" as you seem to think and both Sox and Libsamplerate are as near perfect as you will ever need. I decline to believe you can hear the difference between 44 and 48Khz that have been resampled between either on high quality. That's not to say that your DAC might not sound different on different settings, so be sure that your test is something like 44->48->44 and then compare original with double converted - I decline to believe you will pass an ABX test on which is which... In fact convert the audio 10 and then 100x forwards and backwards and I still don't expect you to hear a difference...
Good luck
Ed W
RT kernels are all about getting the latency between switching two tasks (to simulate having multiple processors) to be of very low granularity. In fact I think you can usually get away with a normal kernel for nearly all tasks, especially if you tweak your applications a bit
I'm not sure ecasound is special in any way. I'm sure it's also fine though? People get excited about audio daemons but they largely just pass through data unaltered if you configure them correctly. Nearly all apps you might want to use would also work very happily with no audio mixer daemon though and you could talk to Alsa directly?
Alsa also has a very high quality resampler built-in (libsamplerate) - however, note libsamplerate has three modes, I guess read the docs to be sure you are using highest quality. This is largely of similar quality to the new sox resampler (but be aware that old sox versions from a few years ago only had a horrible resampler - the new version is superb quality, the old is duff...)
At the end of the day if you lock your soundcard to the rate you feel it performs best (eg 48Khz), then let Alsa resample everything to that for you, it will do it in excellent quality.
Secondly, although folks whitter on about doing things offline, etc - the computer will internally read quite large chunks of audio data, process these large chunks and then feed these large chunks into to the soundcard where they will be dealt with by a separate "processor" that is completely separate to the main computer. This seems badly understood, but literally the sound card will be fed buffers of say several thousand samples (so between tens and hundreds of millisecs of audio) and left to get on with pumping them out of the DAC however it sees fit
Now we can imagine that the computer can influence the DAC quality, but that influence will be limited to say drawing a bunch of power, causing the PCI powerlines to sag, in turn influencing the DAC... Seems like a bit of a stretch to me? (And if it is an issue then you would be advised to mod your card first rather than **** around in software...)
Just as a stake in the ground, I use Mythtv as my media player, an RME 9632 as the 6 channel DAC and audio is output via the Jack soundserver purely because it allows me to hook in Brutefir to mangle the audio. Brutefir is used to apply some long FIR filters (calculated using DRC) and also to apply crossovers between drivers (I have a 4.2 surround system, ie stereo IB bass and 4 full range speakers on each corner). I run my system at 44Khz so CDs are not resampled, but DVD/TV is resampled from 48Khz down to 44Khz using libsamplerate (myth does this internally, but you could use alsa to do the same). I usually run the system at around 10ms latency, but it works fine at 5ms latency and somewhat below (this is while say playing a 1080P blueray, resampling audio down to 44Khz, convolving 6 channels of audio with massive length FIR filters, all using a non RT kernel and yet it never misses filling an audio buffer)
I doubt the above will suit your needs though, so the question remains what audio player... Hmm, I guess try all the usual culprits such as mplayer, xine, XBMC, mythtv and a google search will turn up a ton of other less well known but very interesting options - see what suits you best? I think the only thing you are likely to find is that several of these players have resamplers of variable quality built-in and so you may need to watch the configuration a little to ensure you don't use the internal resampler, but instead the Alsa resampler (or at least understand which one is being used and the compromises as a result)
Resamplers are poorly understood, but suffice to say there are no "moving averages" as you seem to think and both Sox and Libsamplerate are as near perfect as you will ever need. I decline to believe you can hear the difference between 44 and 48Khz that have been resampled between either on high quality. That's not to say that your DAC might not sound different on different settings, so be sure that your test is something like 44->48->44 and then compare original with double converted - I decline to believe you will pass an ABX test on which is which... In fact convert the audio 10 and then 100x forwards and backwards and I still don't expect you to hear a difference...
Good luck
Ed W
I should probably caveat that Win7 appears to also have a decent audio daemon which doesn't appear to mangle the audio and passes it through at high quality to the soundcard. As such, much as it pains me to say, Win7 should be just as satisfactory for playing audio, at least to the extent you read audio from disk and pass it to the soundcard without mangling it...
Hi Ed.
You obviously did try my recommendations, since you have a pretty strong opinion about anything I am bringing up here.
Though I guess it wouldn't occur to you that there are different systems out there, which might behave different then yours. And which might do have a different quality level then yours.
BTW. I also own a RME9632 with 6 analog outputs and I can tell you that I consider it midfi at best compared to my high quality gear. I'd never use it as a main source.
I btw started with Brutefir 4 years ago which obviously also uses the rt-kernel. The problem with brutefir it is that is not at all maintained and it just sounds worse then ecasound ( under certain conditions of course).
ecasound is IMO the best sounding audio application under Linux. Beside that it is well maintained.
Jack is nothing else then another layer on top of Alsa. If best soundquality is the goal I wouldn't recommend that one either. You wouldn't imagine - but I tried it. Of course if you run multichannel you have to go for it.
I applied some of those tweaks that I figured out over time to the SB Touch
recently. IMO they work quite well on that platform too. ( read some of the users comments on my blog). The great thing with the Touch is now, that everybody can easily reproduce what I am claiming since a while.
BTW: I still don't do active filtering with FIR since you can't avoid losses due to filtering. And I havn't found a highest quality multichannel interface
under Linux which would be able to compete with my stereo interface.
Coming back to the Juli-Card.
I and a couple of friends tested that card ( externally powered and with I2S tapped off) feeding a Sabre-DAC on a CMP2/CPLAY system against my Linux config. My Linux config (not a normal Linux setup) sounded even better then CPLAY/CMP2.
No Ed, this was and still is not Voodoo.
Fact is, the better your DAC or soundcard decouples from the PC induced mess (mainly Emi,RFI, timing and power variations) the less impact
you'll recognize. Another fact is that it needs a highly resolving system
to realize slightest changes.
What doesn't help though, is just to express "opinions" about a subject.
Either you have tested it or not.
As with all tests - if you've done them - the respective test environment should be described properly and sufficiently. Otherwise there is no way to do any benchmarking.
Cheers
You obviously did try my recommendations, since you have a pretty strong opinion about anything I am bringing up here.
Though I guess it wouldn't occur to you that there are different systems out there, which might behave different then yours. And which might do have a different quality level then yours.
BTW. I also own a RME9632 with 6 analog outputs and I can tell you that I consider it midfi at best compared to my high quality gear. I'd never use it as a main source.
I btw started with Brutefir 4 years ago which obviously also uses the rt-kernel. The problem with brutefir it is that is not at all maintained and it just sounds worse then ecasound ( under certain conditions of course).
ecasound is IMO the best sounding audio application under Linux. Beside that it is well maintained.
Jack is nothing else then another layer on top of Alsa. If best soundquality is the goal I wouldn't recommend that one either. You wouldn't imagine - but I tried it. Of course if you run multichannel you have to go for it.
I applied some of those tweaks that I figured out over time to the SB Touch
recently. IMO they work quite well on that platform too. ( read some of the users comments on my blog). The great thing with the Touch is now, that everybody can easily reproduce what I am claiming since a while.
BTW: I still don't do active filtering with FIR since you can't avoid losses due to filtering. And I havn't found a highest quality multichannel interface
under Linux which would be able to compete with my stereo interface.
Coming back to the Juli-Card.
I and a couple of friends tested that card ( externally powered and with I2S tapped off) feeding a Sabre-DAC on a CMP2/CPLAY system against my Linux config. My Linux config (not a normal Linux setup) sounded even better then CPLAY/CMP2.
No Ed, this was and still is not Voodoo.
Fact is, the better your DAC or soundcard decouples from the PC induced mess (mainly Emi,RFI, timing and power variations) the less impact
you'll recognize. Another fact is that it needs a highly resolving system
to realize slightest changes.
What doesn't help though, is just to express "opinions" about a subject.
Either you have tested it or not.
As with all tests - if you've done them - the respective test environment should be described properly and sufficiently. Otherwise there is no way to do any benchmarking.
Cheers
Hi Folks,
I hope I haven't caused a fire here... it wasn't my intention. First of all thanks for your answers but my main question is still unswered!
I would like to understand how to setup ALSA from scratch, but I couldn't find any source online which doesn't assume that you already know how ALSA works. To tell the truth I think ALSA documentation is hard to follow even for a long-term unix user like me. I also noticed that most linux releases install PulseAudio by default and it is annoying to get rid of it. So my practical question is:
1. which of the well supported LINUX distro does not install by default the sound engine?
2. can somebody point me to a source where it is explained in details how to configure ALSA?
I don't know which system performs better. To me PC is only a way to play HD files. At the moment the best way to play red-book stuffs remains my transport. I spent big moneys on my system in the past. I had all the the best transports you can imagine (theta, Cec, Teac, Spectral) and at the end I understood they only sound right if they are able to produce a perfect square wave on the spdif output.
Dear soundcheck latency and jitter is only 1/3 of the story. Let us assume that your data does not show any form of jitter, the problem is how it is transfered to the DAC. My actual transport is an ASUS E818A3... yes a cheap dvd-rom with spdif output powered with a cheap linear psu which sounded better than my venerable Spectral transport... it was a shame I know but the only technical difference was that on the scope the Asus had an almost perfect square wave while the spectral was wrong with that!
Next weak I will try to take my PC with the ESI Juli@ to a local lab to see how the spdif output looks on the scope. I think perfect spdif output is must.
Best Wishes
K
I hope I haven't caused a fire here... it wasn't my intention. First of all thanks for your answers but my main question is still unswered!
I would like to understand how to setup ALSA from scratch, but I couldn't find any source online which doesn't assume that you already know how ALSA works. To tell the truth I think ALSA documentation is hard to follow even for a long-term unix user like me. I also noticed that most linux releases install PulseAudio by default and it is annoying to get rid of it. So my practical question is:
1. which of the well supported LINUX distro does not install by default the sound engine?
2. can somebody point me to a source where it is explained in details how to configure ALSA?
I don't know which system performs better. To me PC is only a way to play HD files. At the moment the best way to play red-book stuffs remains my transport. I spent big moneys on my system in the past. I had all the the best transports you can imagine (theta, Cec, Teac, Spectral) and at the end I understood they only sound right if they are able to produce a perfect square wave on the spdif output.
Dear soundcheck latency and jitter is only 1/3 of the story. Let us assume that your data does not show any form of jitter, the problem is how it is transfered to the DAC. My actual transport is an ASUS E818A3... yes a cheap dvd-rom with spdif output powered with a cheap linear psu which sounded better than my venerable Spectral transport... it was a shame I know but the only technical difference was that on the scope the Asus had an almost perfect square wave while the spectral was wrong with that!
Next weak I will try to take my PC with the ESI Juli@ to a local lab to see how the spdif output looks on the scope. I think perfect spdif output is must.
Best Wishes
K
No -- this discussion is ongoing since 4 years.
I am figuring stuff out and post it over here and other people express their "opinions" about it.
You are not alone.
This discussion also pops up once in a while.phofman will tell you: You're invited to contribute. Alsa is always looking for volunteers.
Alsa is part of the kernel. You just need to take it away from the kernel.
I am not aware of any distro which has Alsa not in by default.
You might try Gentoo.
Good luck.
The respective app should take care on most of the Alsa stuff.
You can also use amixer for certain tasks. If you look for permanent configs or routings etc. have a look at asound.conf configuration examples.
You'll find several on the Alsa pages.
I'd say. It'll depend on your specific case what you got to do.
Since you are a long time Linux guy, you know that "Google will be your best friend". Not any answer will remain unanswered.
I said timing and power variations, EMI, RFI.
Of course there are other physical factors such as connectors, cables parts etc.
What are the 2/3you are looking at?
Advise: Don't forget to try Toslink ( VDH Optocoupler MKII) up to 96khz. This way you'll keep the PC noise away from your DAC.
If you run SPDIF keep them as short as possible ( Dan Lavry mentioned something around 8 inches).
Good luck on your journey. Meanwhile I turn on my 250€ Touch and enjoy.
Cheers
I guess you mean sound daemon, specifically pulseaudio. Debian, gentoo, archlinux - the distributions not intended primarily for desktop. Any decent desktop distribution MUST offer mixing multiple audio streams out of the box and that is where pulseaudio has become a defacto standard now.
What specifically would you like to configure? There are just a few alsa params, mostly handled by your playback app:
1. sample rate - switched automatically by the driver to fit your source audio material. Juli can play natively all the major sample rates, you do not have to set anything. BTW, I do not see any reason anymore to force resampling to a different fs - why not to keep the chain clean and simple without any resampling?
2. buffer size, period size - these two values have a default value defined in your application, usually adjustable. They are set by the application when opening alsa device. The buffer size means lenght in samples of the DMA circular buffer the card reads on its own. If you do not care about latency (music production, audio/video sync), you want to keep this at max value your card can handle. That can be easily identified by playing with parameters of aplay. Period size means after how many samples read independently the card throws in IRQ, informing the driver/the application which part of the buffer has been just finished playing. Applications usually set period to 1/4 -1/8 of the buffer, at least 1/2. The lower the period size, the more CPU load to handle the IRQs, but the lower chances of the app not being awoken up early enough to overwrite the already played buffer regions with fresh audio data. In reality for lightly to medium loaded systems, if you set buffer time to over 1 sec of data and period time to let's say 128ms, you will be just fine. Here you can see that RT kernel cannot bring any sonic improvement.
I would really recommend that you generate samples of music you like in various samplerates, using sox, and spend some time with aplay and its parameters -v, -F, -B (see man aplay) and see what your system does in various combinations of these params and overall load by other programs. You may want to monitor your actual soundcard IRQ rate by issuing:
Code:
watch -n1 "cat /proc/interrupts | grep 1724"Now if you want to mix various audio streams, things get more complicated. You have to choose a common sample rate and either use pulseaudio or the dmix plugin in alsa. For audio material which does not require resampling, i.e. the common sample rate, the audio quality of dmix and pulseaudio will be the same - they both are bit perfect (if pulseaudio is configured to use HW controls and the individual application volume is set to 0dB). Pulseaudio will consume noticeably more CPU since it uses a rather complicated buffer management, using high resolution timers to track the already played samples, instead of the sound card IRQs.
If resampling is required, I cannot compare pulseaudio to dmix since I have not studied pulseaudio sources. Quick look at dmix code reveals that it does use the revered libsamplerate, BUT all samples get cut to 16bit first. AFAIK there is no 24/32bit quality resampling algorithm in dmix. For me this is a serious limitation but the reality is dmix is being slowly deprecated in favour of pulseaudio and maintainers do not have any further plans with it.
For a dedicated audio playback machine I would avoid mixing alltogether and configure the playback SW to use plughw device directly. The plug plugin is harmless and desirable as it makes sure the driver always gets only formats/samplerates the card supports physically.
Decent SPDIF transports feature an output isolation transformer which cannot produce perfect squares, due to its limited bandwidth. Juli has three 7404 gates in parallel feeding the output transformer. You will see rounded corners on your scope, just as I did
soundcheck said:
No there aren't - there really aren't. Every system behaves exactly as Ed suggests. These are computers.
soundcheck said:
Losses? Can you give a bit more detail? FIR filtering is pretty clean, needing only a single quantisation at the end. Designing the coefficients to perform well is a complex topic that fills many involved books, but if you do that properly, FIR filtering is very general and powerful.
soundcheck said:
This one is the hardest to reconcile for me - surely you don't consider your suggestions to be objective and repeatable. You try a random combination of software tweaks, none of which seem to have any justification beyond hand-waving, and say they "sound better", all the while trashing the ears and system of the only guy in here who tries to say anything useful. I would urge people interested in PCs for serious audio to look beyond your ideas.
kephaudio said:
I would advise that this is a mistaken conclusion, and that there must have been other differences between the two SPDIF signals that weren't visible from a scope. To be fair, looking at these kinds of signals using only a scope isn't a very good way to discern much information about them. In any case, all perfect square waves get you over band-limited ones is EMI problems. Reproducing perfect square waves isn't usually the aim in digital comms - and nor should it be. Band-limited waveforms can include all of the data and timing information present in the signal, and are less subject to cable issues (reflections, radiating off the cable, ringing, etc).
Moving on.
I would recommend Gentoo as a linux distro. I use this both on my desktop machine and my digital crossover box, and it's great in both roles. In particular, you have to install any and all software components you want - nothing is assumed or bundled, and you can get a nice minimal software system without actually trying. I myself run JACK (with the ALSA backend directly on the hardware) on top of my RME HDSP9652 card, with some homegrown crossover signal-processing software, and it works flawlessly down to 44.1kHz/3ms latency on an old Athlon64 2800+ at 800MHz. I usually run it at 6ms to give it a bit more headroom in the case of processing spikes, and don't notice any lip-sync issues.
I do have an issue with JACK's int-float conversion method (it isn't transparent), but I know from past experience that the developers are very unlikely to change their minds about the one they've chosen. I might make a patch for it and put it up somewhere, because I think their reasoning is flawed. Such is the joy of open-source!
I don't think he said that the only important thing is SPDIF output. In my experience having a good square is a must. All good sounding CDP I have heard resulted to have a very good square wave on the SPDIF. There is *empirical literature* on the subject out there.
The digital receiver is designed to read data from a square wave, nothing else.
Best Wishes
Pierre
you're right man. Linuxers love to be snobby so you have you try yourself. Get in touch on linux forums they will help you.
1. I am a long-time debian user and I would suggest to use it. It is well supported, even though debainers are a bit snobby, you can ask help on Ubuntu forums where people are nicer and less "mysterious".! When I installed Debian 4.0 I had to install ALSA myself. It doesn't come with the Pulse/Jack stuffs on top of it as default, so I guess It fulfills your needs. Ask others for confirmation. I don't know about the Debian 5.0.
2. Look at Debian-Alsa wiki. Then start to try and get feedback from debian-ubuntu forums.
I agree 100%. The Spectral is the best transport I heard... too expensive for me, but it is the best red-book device ever produced (imho). Spdif square wave is important, right.
Cheers
Pierre
Last edited by a moderator:
I'm not sure why, but ok, I'll bite...
You have an argumentative writing style. In particular as I said already, you usually aren't making "incorrect" assertions, but what you are doing regularly is linking disparate and barely related claims together in a single sentence. eg here you try and link together an assertion that I'm making a bunch of strong opinions with a statement about whether I have tried your "recommendations". This writing style is usually used so that the poster has the option to make a whole range of counter arguments if only a single factor of the sentence is disputed - it's also tiresome
See where is this coming from? This is just an irrelevant personal attack?
Especially when my email reads:
This is an odd statement. Personally I'm of the *opinion* that the DAC is rarely the weakest point in the audio chain, for sure it can often be improved, but the question is whether it makes much difference compared with say changing the transducers... But certainly in my *opinion* it would be very hard to disparage any DAC with measured 110dB performance? (Anyone got an example of a DAC with stats in this kind of level which is generally agreed to be of "poor quality"?)
Well brutefit does not output audio as such so it's hard to imagine what you mean? In fact if you configure any audio server (eg ecasound) to avoid resampling or otherwise touching the audio then it's hard to imagine how shuffling bytes around (perfectly) can make any audible difference?
You state Brutefir is "unmaintained", but the authors own page states that it's "complete", but you should let him know if you find a bug because he still intends to fix those? I posted a bug some time past and he fixed it promptly. Why do you say "unmaintained"? Do you have an example of a bug he is refusing to fix?
Jack is a soundserver, it does not sit on top of Alsa. It runs on Windows for a start (and there is no Alsa for windows that I know of?)
Jack is an *API* to allow arbitrary filters to be inserted into a filter chain. Audio is then stuffed in one end and you get a bunch of filtered audio out of the other end. If you use no filters then the output perfectly matches the input.
Once the bytes come out of the other end you need to feed them to some audio layer, eg ecasound, pulse, alsa, oss, osx/windows audio apis, or particularly cool you can even forward the audio over a network socket to a different type of machine somewhere else on your network...
- Attach your spdif output to your spdif input
- Record the spdif input
- Use aplay or similar to play a file through spdif
- Now setup Jack to simply forward input to output (no filters). Use Alsa as the input and output sources
- Again use aplay to play the same file through jack and record the output
Apart from a single empty buffer offset the two files will be byte by byte equal....
Someone will probably ask why even bother. Well actually one does exactly this to measure impulse response measurements of stuff, ie the process of measuring your speakers is to send a known signal through them, measure it, then compare the measured response with the original. The maths uses means that if you tweak your system and connect the digital output to the digital input and run the same test then you measure the performance, delay and phase response of your audio card instead, curiously this will turn out to be a dirac response on anything other than a broken system, ie output is exactly equal to input...
Why does Jack have to do with multichannel? Why would you have to use it for multichannel and not something else?
To recap:
- Jack is for applying filters to your audio, it doesn't care how many channels you use.
- Ecasound is a sound server used for mixing together multiple audio streams (nothing else).
- Finally Alsa is used to drive the audio hardware itself, ie to take a series of bytes out of (say) Ecasound and get them into the audio card.
We are talking about Jack, Ecasound and Alsa and you write the above? Are you sure this is what you mean? Seems to have nothing to do with this?
Mathematics on a computer is done to a given precision and the "losses" can be made arbitrarily small depending on your needs or requirements. Brutefir will happily process double precision figures if you request it to. This means in excess of 384dB of linear range if you need it. (ie processing 8-12bit audio input with 64-80 bits of precision)
If you want to compute some kind of filter, eg a crossover for a driver, etc, then you will NOT compute it with greater precision using passive analogue components, nor even active analogue components... (I will concede that there are a couple of pathological filters that burst the absoluteness of this claim, but they are rather exceptional situations rather than the norm)
The "voodoo" is your switch from the topic under discussion to some other topic where you make a point that is indisputable, followed by a conclusion that really relates to this second point, but is designed to suggest that your whole post is correct by inference
eg here where you switch from your incorrect assertions about the way linux applications fit together to some untestable assertion that some setup you listened to is better than some other setup you listened to, and then you suddenly jump back to an assertion about Voodoo...
It's a classic argumentative style to try and prove one small point and then make this one conclusion expand to prove all the other points in the post...
So just like all your detailed assertions about how Brutefir passing out identical bytes to ecasound somehow sounds different? Nice one...
Look, I could go on knocking down your incorrect assertions (eg you started dribbling down a route suggesting that someone remove all their Alsa modules from their kernel and still expect to get some audio out of their machine?!?!? You clearly don't understand that under a linux kernel the only way you get audio out of your precious Ecasound daemon and into the onboard soundcard is via Alsa (or perhaps OSS if you installed that instead). Alsa *is* your audio card drivers (under linux) (...obviously you can use a network connected soundcard without Alsa, but that's not really the point)
....However, there are a limited number of hours in the day....
Look, good on you for progressing this, but please, please just keep your tests simple and your conclusions straightforward and testable. If you just change your writing style to avoid linking several reasonable and helpful statements together with two handwaving statements and then getting upset when someone tackles the handwaving part, then everyone will be happier?
Good luck
You have an argumentative writing style. In particular as I said already, you usually aren't making "incorrect" assertions, but what you are doing regularly is linking disparate and barely related claims together in a single sentence. eg here you try and link together an assertion that I'm making a bunch of strong opinions with a statement about whether I have tried your "recommendations". This writing style is usually used so that the poster has the option to make a whole range of counter arguments if only a single factor of the sentence is disputed - it's also tiresome
See where is this coming from? This is just an irrelevant personal attack?
Especially when my email reads:
This is an odd statement. Personally I'm of the *opinion* that the DAC is rarely the weakest point in the audio chain, for sure it can often be improved, but the question is whether it makes much difference compared with say changing the transducers... But certainly in my *opinion* it would be very hard to disparage any DAC with measured 110dB performance? (Anyone got an example of a DAC with stats in this kind of level which is generally agreed to be of "poor quality"?)
Brutefir is a software application. It does not "use the rt-kernel". It is a software application (run it on the operating system or kernel of your choice - it runs on other operating systems than linux even...)
Well brutefit does not output audio as such so it's hard to imagine what you mean? In fact if you configure any audio server (eg ecasound) to avoid resampling or otherwise touching the audio then it's hard to imagine how shuffling bytes around (perfectly) can make any audible difference?
You state Brutefir is "unmaintained", but the authors own page states that it's "complete", but you should let him know if you find a bug because he still intends to fix those? I posted a bug some time past and he fixed it promptly. Why do you say "unmaintained"? Do you have an example of a bug he is refusing to fix?
Jack is a soundserver, it does not sit on top of Alsa. It runs on Windows for a start (and there is no Alsa for windows that I know of?)
Jack is an *API* to allow arbitrary filters to be inserted into a filter chain. Audio is then stuffed in one end and you get a bunch of filtered audio out of the other end. If you use no filters then the output perfectly matches the input.
Once the bytes come out of the other end you need to feed them to some audio layer, eg ecasound, pulse, alsa, oss, osx/windows audio apis, or particularly cool you can even forward the audio over a network socket to a different type of machine somewhere else on your network...
It has no effect on soundquality other than to apply the filters you request???! If you don't want to apply any filters then you wouldn't use it at all. However, just for kicks you should be able to do something like the following:
- Attach your spdif output to your spdif input
- Record the spdif input
- Use aplay or similar to play a file through spdif
- Now setup Jack to simply forward input to output (no filters). Use Alsa as the input and output sources
- Again use aplay to play the same file through jack and record the output
Apart from a single empty buffer offset the two files will be byte by byte equal....
Someone will probably ask why even bother. Well actually one does exactly this to measure impulse response measurements of stuff, ie the process of measuring your speakers is to send a known signal through them, measure it, then compare the measured response with the original. The maths uses means that if you tweak your system and connect the digital output to the digital input and run the same test then you measure the performance, delay and phase response of your audio card instead, curiously this will turn out to be a dirac response on anything other than a broken system, ie output is exactly equal to input...
Why does Jack have to do with multichannel? Why would you have to use it for multichannel and not something else?
To recap:
- Jack is for applying filters to your audio, it doesn't care how many channels you use.
- Ecasound is a sound server used for mixing together multiple audio streams (nothing else).
- Finally Alsa is used to drive the audio hardware itself, ie to take a series of bytes out of (say) Ecasound and get them into the audio card.
We are talking about Jack, Ecasound and Alsa and you write the above? Are you sure this is what you mean? Seems to have nothing to do with this?
OK, so you are claiming that "sample = sample * 1.0" somehow looses "quality" now?
Mathematics on a computer is done to a given precision and the "losses" can be made arbitrarily small depending on your needs or requirements. Brutefir will happily process double precision figures if you request it to. This means in excess of 384dB of linear range if you need it. (ie processing 8-12bit audio input with 64-80 bits of precision)
If you want to compute some kind of filter, eg a crossover for a driver, etc, then you will NOT compute it with greater precision using passive analogue components, nor even active analogue components... (I will concede that there are a couple of pathological filters that burst the absoluteness of this claim, but they are rather exceptional situations rather than the norm)
Bah, a multichannel interface is just a couple of stereo interfaces put together.
The "voodoo" is your switch from the topic under discussion to some other topic where you make a point that is indisputable, followed by a conclusion that really relates to this second point, but is designed to suggest that your whole post is correct by inference
eg here where you switch from your incorrect assertions about the way linux applications fit together to some untestable assertion that some setup you listened to is better than some other setup you listened to, and then you suddenly jump back to an assertion about Voodoo...
It's a classic argumentative style to try and prove one small point and then make this one conclusion expand to prove all the other points in the post...
So just like all your detailed assertions about how Brutefir passing out identical bytes to ecasound somehow sounds different? Nice one...
Look, I could go on knocking down your incorrect assertions (eg you started dribbling down a route suggesting that someone remove all their Alsa modules from their kernel and still expect to get some audio out of their machine?!?!? You clearly don't understand that under a linux kernel the only way you get audio out of your precious Ecasound daemon and into the onboard soundcard is via Alsa (or perhaps OSS if you installed that instead). Alsa *is* your audio card drivers (under linux) (...obviously you can use a network connected soundcard without Alsa, but that's not really the point)
....However, there are a limited number of hours in the day....
Look, good on you for progressing this, but please, please just keep your tests simple and your conclusions straightforward and testable. If you just change your writing style to avoid linking several reasonable and helpful statements together with two handwaving statements and then getting upset when someone tackles the handwaving part, then everyone will be happier?
Good luck
I use Gentoo almost exclusively and find it excellent for *my* needs. However, I would hesitate to recommend it to anything other than an expert audience? I would suggest that *probably* mainstream distros which just work out of the box are the best bet for most users reading this thread?
eg the Redhat, Ubuntu big distros, or perhaps more specialised smaller distros for the slightly more advanced, eg Soundcheck's Voyager suggestion, perhaps Puppy, DSL or any of these other micro-distros. Debian probably falls somewhere in the middle of the these?
For the really advanced users then personally I like Gentoo, but also you have other sourced based distros and very customisable distros such as Arch. SPBlinux is a really off the wall gentoo derivative that fits in a few MB and you can get a basic audio configured version from Uli's Accourate website... Great for those who know what they are doing, but probably not great for the likely average reader of this thread (no disrespect intended - use the right tools for the job and all that)
Lots of options, but personally if you are a not a linux hero and have the storage space then I would recommend distros which work fairly easily straight out of the box...
Good luck
eg the Redhat, Ubuntu big distros, or perhaps more specialised smaller distros for the slightly more advanced, eg Soundcheck's Voyager suggestion, perhaps Puppy, DSL or any of these other micro-distros. Debian probably falls somewhere in the middle of the these?
For the really advanced users then personally I like Gentoo, but also you have other sourced based distros and very customisable distros such as Arch. SPBlinux is a really off the wall gentoo derivative that fits in a few MB and you can get a basic audio configured version from Uli's Accourate website... Great for those who know what they are doing, but probably not great for the likely average reader of this thread (no disrespect intended - use the right tools for the job and all that)
Lots of options, but personally if you are a not a linux hero and have the storage space then I would recommend distros which work fairly easily straight out of the box...
Good luck
WDYSUN said:
Well, I'm sure they all had PCB tracks made of copper and a little light that showed when the machine was switched on, too. How have you shown any relationship whatsoever between square-looking SPDIF outputs and good sound?
WDYSUN said:
I hate to be that guy, but can you link to any? Note that some guy saying "it sounds better if you do it this way" doesn't really qualify for the title of empirical literature. If it's not based on fair listening tests then it's worthless.
WDYSUN said:
Way to disregard everything quantitative I said, man. A digital receiver is designed to sample its input voltage at a clock instant. In a signal-derived clock system like S/PDIF, the clock instants are determined from the zero-crossing points. Once the receiver has its clock reference, it samples the analogue signal waveform at the right times to determine if the voltage is high or low. What the signal does at other times, it doesn't know or care about.
It makes sense then that you'd try to create a waveform that would give the voltage the best chance being correct at the clock instance, rather than blindly making a square wave because you think it looks prettier. The accuracy of the S/PDIF signal regards to timing information has nothing inherently to do with how square the waveform is.
If your receiver is deriving its clock signal from the S/PDIF input, then it's never going to be able to completely decouple itself from the timing accuracy of that signal. Sensible people use their DAC as the master clock source, or at a push incorporate a FIFO buffer and a tunable local oscillator. Then the quality of the S/PDIF signal becomes effectively irrelevant and the whole discussion should be over.
Most serial data links (like SPDIF and AES-EBU) benefit from equalization to boost the HF to reduce jitter. Its even part of the AES3 spec. Square isn't necessarily right. Properly applied equalization can actually reduce the received jitter. Modern receivers use the short space to decode the clock and use a PLL to lock to it. That seems to be the least interfered by the data. The really fast risetimes that make a good looking square wave can actually cause a lot of EMI interference, which could degrade the sound.
ewildgoose... Just like to say I agree with all your comments, especially about Brutefir and filtering.
I was going to reply to soundcheck's posts but your reply is better than the one I intended to write.
Second.
I'm Jonny come lately to this debate, but here's my 2c..
I use all three main flavors of OS, along withe several variants of each on a dialy basis.
Personally when i'm in the studio I'm all about speed, creativity and enjoying myself. To which end I run a pair of macs in there as my primary machines, but there's at least one windows box to had at any time. They're all a lot of fun to use when you stay in their sweetspots. Sweetspots or fun have yet to happen when I've had a Linux box in there. Nothing against the OS, or even the tools on it, it's just that they don't float my boat Vs ProTools, Logic and Ableron live. I OWN them all, and It would be a hard sell to get me to ditch them.
I'm tools driven, not platform driven. If there is a great tool for something I care not if it's a debian or red hat linuxen, osx, other bsd, or enen windows in it's countless flavors. If it kicks butt I'll use it.
Not found anything that is compelling in Linux land for studio audio, but it's only a matter of time.
Rob
I use all three main flavors of OS, along withe several variants of each on a dialy basis.
Personally when i'm in the studio I'm all about speed, creativity and enjoying myself. To which end I run a pair of macs in there as my primary machines, but there's at least one windows box to had at any time. They're all a lot of fun to use when you stay in their sweetspots. Sweetspots or fun have yet to happen when I've had a Linux box in there. Nothing against the OS, or even the tools on it, it's just that they don't float my boat Vs ProTools, Logic and Ableron live. I OWN them all, and It would be a hard sell to get me to ditch them.
I'm tools driven, not platform driven. If there is a great tool for something I care not if it's a debian or red hat linuxen, osx, other bsd, or enen windows in it's countless flavors. If it kicks butt I'll use it.
Not found anything that is compelling in Linux land for studio audio, but it's only a matter of time.
Rob
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.