soundcheck said:
Actually, HDMI dedicates a balanced pair of lines to pixel clock, also used by the audio signal, so there's no clock recovery needed. You do have to regenerate your DSP/DAC clock from the pixel clock, but since the pixel clock is constant there's no data-dependent jitter. HDMI really is the next generation of audio interface, in my opinion.
Daveis said:
I haven't seen anything like say Thuneau's Allocator that is a purpose-build xover app, but you can get the job done with something like jackrack and some basic biquad ladspa plugins. Here is the first promising google hit I got.
http://www.suse.de/~mana/ladspa.html
You can certainly get a lot of mileage out of IIR's, but I really think FIR filters are the killer app for PC based audio, linux in particular. I haven't tried it yet, but 'jconv' takes the partitioned convolution idea that BruteFIR uses and extends it to non-uniform partition sizes. This reduces the latency, but appears to keep the cpu usage fairly moderate. Link is
http://www.kokkinizita.net/linuxaudio/
There are several very cool looking apps at that link.
Digression/aside
I've been out of the Linux audio world for quite a while, having ventured over into windows using Allocator with my Emu 1820m. Now that support for the Emu cards is kinda-sorta working, I took the time to throw Ubuntu Studio on the machine. Duplex audio isn't working right on the Emu so I had to spend some time also installing my Delta 66, but aside from that I was quite pleasantly surprised with how quickly things came up. For the first time ever I got 'one shot' results with DRC that were very good, and aside from DRC itself everything was an apt-get rather than a build from scratch. audacious->brutefir->jack->alsa/Emu.
My plan is to look at MPD next, as there is a native client available for the Nokia 770 I'm planning to use as my interface/remote. First try using the native jack interface failed, unfortunately.
Daveis said:
Unless you already have a fair bit of linux experience (and maybe even if you do) I'd suggest a two-stage approach.
Stage 1 - start with a well supported distro, and work with that until you get a software chain that you're happy with.
Stage 2 - move that software chain to an embedded style environment. The 'brutefir on a stick' idea from the DRC wiki site (duffroomcorrection.com) might be a place to look for a template.
IMHO starting with UbuntuStudio is probably as good a bet as any right now. It includes a kernel with the mainstream RT patches (not the super-exotic stuff discussed here), but builds on Ubuntu which means that everything just pretty much works. The RT patches seem pretty good - when running jack non-RT, I was getting a lot of xruns, even with no activity. Reconfiguring with jackd running RT I've run all day with all sorts of apt-get etc activity with no xruns. Maybe not 'the best', but pretty good.
http://www.ubuntustudio.org
So, my mpd problem was user error - running jackd and mpd with different userid's. I'm now up an running with MPD->brutefir(DRC)->jack(RT)->Emu 1820M (analog) . I'm using phpMp as the control interface, accessing via my Nokia 770. Very very cool. Easily the best sound I've obtained since getting the U15's (although my system has been in such flux that may not be as strong an endorsement as it sounds)
I'm running just a basic stereo/DRC system - no xovers at the moment. Next step is to get some subs integrated (my Yorkville U15's are *almost* enough without subs, but not quite enough to prevent me from at least trying). After that, I'll eval the idea of active xovers for the U15's.
Hi.
I agree with dwk123.
With Ubuntustudio you'll get one of the best supported distros.
However official distributions are always behind the latest kernel developments. For Ubuntu Gutsy Gibbon you can install ready made
RT packages without compiling a new kernel.
https://wiki.ubuntu.com/RealTime/Gutsy
You might want to have a look here:
http://rt.wiki.kernel.org/index.php/Main_Page
In the near future there is no need to patch the kernels any longer for the basic rt setup on the next Ubuntu releases.
Since 2.6.23 the Ingo Molnar - patchset (cfs-scheduler) is part of the kernel.
However. E.g. the ZEN patchset is still performing far better.
If you read the Wiki - I wouldn't call the customized kernel installation "super-exotic" any longer.
"brutefir on the stick" is IMO not recommended for beginners.
You'll get very limited applications and support for it.
If you run into issues, you'll not be able to solve them by yourself.
Cheers
Klaus
I agree with dwk123.
With Ubuntustudio you'll get one of the best supported distros.
However official distributions are always behind the latest kernel developments. For Ubuntu Gutsy Gibbon you can install ready made
RT packages without compiling a new kernel.
https://wiki.ubuntu.com/RealTime/Gutsy
You might want to have a look here:
http://rt.wiki.kernel.org/index.php/Main_Page
In the near future there is no need to patch the kernels any longer for the basic rt setup on the next Ubuntu releases.
Since 2.6.23 the Ingo Molnar - patchset (cfs-scheduler) is part of the kernel.
However. E.g. the ZEN patchset is still performing far better.
If you read the Wiki - I wouldn't call the customized kernel installation "super-exotic" any longer.
"brutefir on the stick" is IMO not recommended for beginners.
You'll get very limited applications and support for it.
If you run into issues, you'll not be able to solve them by yourself.
Cheers
Klaus
Looks like ubuntu studio would be a good place for me to start.
Real time support seems to be getting more mainstream with each release.
This has probably been asked before.... but here goes.
With a real-time or hard real time kernel what defines priority?
I may have several pieces
a) sound card device driver
b) hard drive driver
c) media/music player
d) jackrack
e) ladspa plugin
For it to work each of these needs to be streaming smoothly to the next?
Or should specific priorities be made such that the sound card gets most priority somehow.
Is it more a matter of having the R/T kernel or do you have to go to a lot of work defining priorities beyond that?
Real time support seems to be getting more mainstream with each release.
This has probably been asked before.... but here goes.
With a real-time or hard real time kernel what defines priority?
I may have several pieces
a) sound card device driver
b) hard drive driver
c) media/music player
d) jackrack
e) ladspa plugin
For it to work each of these needs to be streaming smoothly to the next?
Or should specific priorities be made such that the sound card gets most priority somehow.
Is it more a matter of having the R/T kernel or do you have to go to a lot of work defining priorities beyond that?
http://tapas.affenbande.org/wordpress/?page_id=40
I think this guys pages really explain well, in simple terms, the low latency/rt setup and touches on most of the parameters that have been discussed on this thread/wiki. The page linked shows how applications and the soundcard are prioritised with respect to one another through real time scheduling. This set up is optimised for music production, I believe Klaus' recommendations are a bit different where midi and jack are not considerations, and have more extreme system timer and real time clock settings (afforded by the zen-sources rather than the real pre-emption patch on its own). You should ensure that you have tweaked all of these parameters once you have installed the kernel as each system will be different.
The only thing on your list that isn't mentioned on the above pages is the hard drive. Con Kolivas' wiki, and numerous others, discuss how hard drives and their file systems (usually ext3) can be tuned for faster reading and therefore lower latency. However, I believe playing files from RAM would make the access time of the hard drive a non issue for playback only systems.
Ross
I think this guys pages really explain well, in simple terms, the low latency/rt setup and touches on most of the parameters that have been discussed on this thread/wiki. The page linked shows how applications and the soundcard are prioritised with respect to one another through real time scheduling. This set up is optimised for music production, I believe Klaus' recommendations are a bit different where midi and jack are not considerations, and have more extreme system timer and real time clock settings (afforded by the zen-sources rather than the real pre-emption patch on its own). You should ensure that you have tweaked all of these parameters once you have installed the kernel as each system will be different.
The only thing on your list that isn't mentioned on the above pages is the hard drive. Con Kolivas' wiki, and numerous others, discuss how hard drives and their file systems (usually ext3) can be tuned for faster reading and therefore lower latency. However, I believe playing files from RAM would make the access time of the hard drive a non issue for playback only systems.
Ross
flash memory used in usb sticks can only be written to a certain number of times before it begins to fail. For all they cost, this is not such a big deal and it probably would be quite a while before this actually happened.
USB speed is also a lot lower than even the slowest of ram speeds - which I would assume is a factor worth considering. If you are running a usb dac then you would be using another device on the same bus - it is recommended that you have as few devices on usb or pci (often the same) as possible if your audio device is running off these.
Would be quick to give it a go yourself.
cheers,
Ross
USB speed is also a lot lower than even the slowest of ram speeds - which I would assume is a factor worth considering. If you are running a usb dac then you would be using another device on the same bus - it is recommended that you have as few devices on usb or pci (often the same) as possible if your audio device is running off these.
Would be quick to give it a go yourself.
cheers,
Ross
I believe most of the USB/CD-ROM Linux distributions decompress the file system into a special memory ram-drive.
Once the system is booted you can remove the CD-ROM or USB stick and it will still function.
Very good idea for a appliance type device such as a crossover/DRC machine that maybe also has a web based media player.
USB flash drives are cute and small... but just how small and quiet do you need it?
For the cost of a flash drive you can get an 80-160 GB laptop drive with USB2 interface. Its faster, cheaper per GB, and can function as a swap device without fear of destruction.
Once the system is booted you can remove the CD-ROM or USB stick and it will still function.
Very good idea for a appliance type device such as a crossover/DRC machine that maybe also has a web based media player.
USB flash drives are cute and small... but just how small and quiet do you need it?
For the cost of a flash drive you can get an 80-160 GB laptop drive with USB2 interface. Its faster, cheaper per GB, and can function as a swap device without fear of destruction.
If I understand Soundchecks logic on the hardware side, he is eliminating any subsystem that will introduce noise to the sound path. Thus he moves the music to be played to a ram disk, then shuts down the hard drive & monitor. Using a USB hard drive would introduce a new source of noise to the environment.
bluemartini said:
Electrical noise or acoustic noise? My laptop USB drive is dead silent in operation.
I can't say the same for my SATA 3GB internal drives. Those make a whirring sound even with fluid dynamic bearings.
The Western Digital Passport external drives are:
Acoustic Specifications
60 GB 80 GB 100 GB 120 GB 160 GB 250 GB 320 GB
Idle Mode (average dBA) 17 dBA 20 dBA 20 dBA 20 dBA 20 dBA 20 dBA 20 dBA
Seek Mode (average dBA) 18 dBA 21 dBA 21 dBA 21 dBA 21 dBA 21 dBA 21 dBA
I think booting the OS into ram from usb and using a usb stick as a ram drive or swap are quite different things. If you try puppy linux you can really see the difference in speed running from ram makes, particularly on older systems. Usb is slower than ram, ide or sata, so to use it in place of one of these for swap is only going to be beneficial if you must use swap (due to lack of ram) and you dont have enough space on your harddrive to have a swap partition. Even then you're probably better off trimming your system down so that you have even ram to not have to use swap.
Advice from dunndatt earlier in this thread was to turn swap off and make sure you have enough ram for the job. Switching between ram and swap can unexpected loads on the system and cause interruptions to the audio.
Dont really think the electrical noise/acoustic noise of external usb drives is the main issue. I'd imagine they cause less noise to the system than an internal drive.
Where you are concerned with reducing the interruptions to the audio stream using the usb bus, it is not ideal to introduce new usb devices as these will be requesting processor time through the same bus, which may cause undesirable drop outs. On some motherboards pci, usb, ide etc. are all on the same controller, so it may make little difference which interface you use.
Cics guide over at audioasylum discusses electrical noise of hard drives, suggesting sata is best interface in this regard.
Cheers,
Ross
Advice from dunndatt earlier in this thread was to turn swap off and make sure you have enough ram for the job. Switching between ram and swap can unexpected loads on the system and cause interruptions to the audio.
Dont really think the electrical noise/acoustic noise of external usb drives is the main issue. I'd imagine they cause less noise to the system than an internal drive.
Where you are concerned with reducing the interruptions to the audio stream using the usb bus, it is not ideal to introduce new usb devices as these will be requesting processor time through the same bus, which may cause undesirable drop outs. On some motherboards pci, usb, ide etc. are all on the same controller, so it may make little difference which interface you use.
Cics guide over at audioasylum discusses electrical noise of hard drives, suggesting sata is best interface in this regard.
Cheers,
Ross
Hi.
Ross - you pretty much brought it to the point.
Good that you mention Cics.
He figured out that eSata drives with an external power supply do reduce the jitter.
Some issues:
HDD generate beside the normal read/write and buffering access:
a. power consumption, which might impact the noise floor and
the power stability in the system.
If you have a poor motherboard and/or powersupply you'll face issues on regulators
and clocks causing the known consequences, potentially even
your internal soundcard might be impacted
b. heat & vibrations
The HDD generates extra heat and vibrations. With these you'll
face indirect impact on other devices e.g. more fan usage .
c. Interrupts
There are quite some ACPI events associated directly and
indirectly causing potenially several thousands hick-ups per minute
Of course nobody can really say what's actually causing the degradation. And I personally do not intend to find that out.
I just try to limit the impact.
My recommendation would be eSata drives externally powered
BTW: I do turn my swap off with swapoff -a.
Booting and working from a memory stick is of course much slower than eSata. This will slowdown the whole handling. And if it is USB
it will collide with your USB audiostream if you run an USB-DAC.
Cheers
Klaus
Ross - you pretty much brought it to the point.
Good that you mention Cics.
He figured out that eSata drives with an external power supply do reduce the jitter.
Some issues:
HDD generate beside the normal read/write and buffering access:
a. power consumption, which might impact the noise floor and
the power stability in the system.
If you have a poor motherboard and/or powersupply you'll face issues on regulators
and clocks causing the known consequences, potentially even
your internal soundcard might be impacted
b. heat & vibrations
The HDD generates extra heat and vibrations. With these you'll
face indirect impact on other devices e.g. more fan usage .
c. Interrupts
There are quite some ACPI events associated directly and
indirectly causing potenially several thousands hick-ups per minute
Of course nobody can really say what's actually causing the degradation. And I personally do not intend to find that out.
I just try to limit the impact.
My recommendation would be eSata drives externally powered
BTW: I do turn my swap off with swapoff -a.
Booting and working from a memory stick is of course much slower than eSata. This will slowdown the whole handling. And if it is USB
it will collide with your USB audiostream if you run an USB-DAC.
Cheers
Klaus
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.