If you want everything in RAM disk, you should perhaps look at puppy linux again. The whole os is only 80mb and loads into ram by default. It also has graphical frontends for installing the system to either a usb pen or flash card in ide adaptor - very easy. The application packages are called dotpups and someone has already compiled ecasound as a dotpup, which can be installed using a similar manager to ubuntu etc. There are a lot of other audio applications already packaged.
There is atleast one member of the forum who has patched the kernel for low latency, I tried once but is was the first time I had done anything like this and I messed up. Will try again when I have time (not too quick on a 700mhz cyrix). The forum is very active and forgiving of those new to linux; the community is like those of larger distributions.
You could have both ecasound and the patched kernel running from RAM with enough space to hold a good few tracks in there as well.
There is atleast one member of the forum who has patched the kernel for low latency, I tried once but is was the first time I had done anything like this and I messed up. Will try again when I have time (not too quick on a 700mhz cyrix). The forum is very active and forgiving of those new to linux; the community is like those of larger distributions.
You could have both ecasound and the patched kernel running from RAM with enough space to hold a good few tracks in there as well.
rossco_50 said:
Hi Ross.
THX for the hint.
I'd also need to install brutefir.
Perhaps it's worth a try! (Though It'll end up in a lot of work I guess.)
I am currently booting up in single-user mode (recovery mode) as root anyhow and don't even start X any longer.
Somebody around who can give me hint on following:
Even though I don't have the X-environment up'n running a
screensaver jumps in on the alpha-numeric display.
What kind of daemon is in charge for that behavior?
Does somebody (peufeu!?) have a clue how to switch off the alpha-numeric display with a command.
XSET dpms ... just works under X of course!
Cheers
Klaus
Klaus,
I was really thinking given that you are able to patch kernels, and most of the applications you will need are already packaged, using puppy would be the easy way to get a usb pen drive boot, with applications and kernel in ram.
Unless brutefir has particular issues, it should be relatively easy to make it into a dotpup. see below for a guide.
http://www.puppylinux.org/wikka/DotPupHowToMake
Dont know anything about screensavers, but sounds like something that could be turned off once located.
Ross
I was really thinking given that you are able to patch kernels, and most of the applications you will need are already packaged, using puppy would be the easy way to get a usb pen drive boot, with applications and kernel in ram.
Unless brutefir has particular issues, it should be relatively easy to make it into a dotpup. see below for a guide.
http://www.puppylinux.org/wikka/DotPupHowToMake
Dont know anything about screensavers, but sounds like something that could be turned off once located.
Ross
soundcheck said:
Hi Ross.
THX for the hint.
I'd also need to install brutefir.
Perhaps it's worth a try! (Though It'll end up in a lot of work I guess.)
I am currently booting up in single-user mode (recovery mode) as root anyhow and don't even start X any longer.
Somebody around who can give me hint on following:
Even though I don't have the X-environment up'n running a
screensaver jumps in on the alpha-numeric display.
What kind of daemon is in charge for that behavior?
Does somebody (peufeu!?) have a clue how to switch off the alpha-numeric display with a command.
XSET dpms ... just works under X of course!
Cheers
Klaus
Hi (this is my first post on this forum),
Try "setterm -blank 0" to turn off the "screensaver" on the console.
Johan
Seagate has a DFT on both floppy and CDROM. I use that from time to time when the floppy version fails for one reason or the other.
Usually what I'll do is download the floppy versions and set them up in grub so I don't have to keep track of floppies laying around. So long as the hard disk works enough to boot the gzip floppy image, this isn't a problem. I also do this with memtest and a few other config disks.
Unfortunately I had to use this on my old laptop the other day...and it was very convenient.
-----
Kernel recompiling: when eating an elephant, do so one byte at a time.
When stripping down kernels, be careful and do one major piece at a time. The extra code really doesn't hurt a lot, it just takes up extra RAM. This method may seem slow...and it rightfully is...but it is faster than trying to cut everything out and not knowing what all that is.
Before compiling, you can copy out the ".config" file to somewhere safe and rename it accordingly. If something screws up, it's real easy to copy it back to a known working condition.
Trust me on this one. I've done it a lot.
-----
If someone just wants to goof off, knoppix has an insane amount of custom versions:
http://knoppix.net/wiki/Knoppix_Customizations
Some are better than others depending on original design requirements.
To get knoppix into RAM, use the "toram" keyword on the boot prompt.
There are also other keywords that can be used to disable unwanted hardware features.
-----
Ethernet playback: Since SoundCheck likes small buffers, this probably wouldn't work well for him. Those of us with 0.5s buffers or larger won't care (this is how I do most of my playing scattered across various servers).
Since linux is multi-tasking, it would be possible with some moderate effort to have another script watching the available disk size and current file being played and then transparently transferring the next file in the background to the RAM disk.
The main draw back of this is that the computer isn't solely focusing on playback and may start skipping a little depending on how good the motherboard is and how old the system is. My dual P3 500 Xeon 2m box would probably start choking on this because the sound chip is actually ISA soldered on the motherboard. My dual P2 450 Xeon 1m would probably do ok as the sound chip is PCI soldered on the motherboard. (aren't old linux systems fun?) I'm not sure how a USB DAC would handle it.
A good PCI ethernet card (name brand) would also help. Cheaper cards tend to skimp where they shouldn't forcing the processor to do more work.
|
-=D=-
|
Usually what I'll do is download the floppy versions and set them up in grub so I don't have to keep track of floppies laying around. So long as the hard disk works enough to boot the gzip floppy image, this isn't a problem. I also do this with memtest and a few other config disks.
Unfortunately I had to use this on my old laptop the other day...and it was very convenient.
-----
Kernel recompiling: when eating an elephant, do so one byte at a time.
When stripping down kernels, be careful and do one major piece at a time. The extra code really doesn't hurt a lot, it just takes up extra RAM. This method may seem slow...and it rightfully is...but it is faster than trying to cut everything out and not knowing what all that is.
Before compiling, you can copy out the ".config" file to somewhere safe and rename it accordingly. If something screws up, it's real easy to copy it back to a known working condition.
Trust me on this one. I've done it a lot.
-----
If someone just wants to goof off, knoppix has an insane amount of custom versions:
http://knoppix.net/wiki/Knoppix_Customizations
Some are better than others depending on original design requirements.
To get knoppix into RAM, use the "toram" keyword on the boot prompt.
There are also other keywords that can be used to disable unwanted hardware features.
-----
Ethernet playback: Since SoundCheck likes small buffers, this probably wouldn't work well for him. Those of us with 0.5s buffers or larger won't care (this is how I do most of my playing scattered across various servers).
Since linux is multi-tasking, it would be possible with some moderate effort to have another script watching the available disk size and current file being played and then transparently transferring the next file in the background to the RAM disk.
The main draw back of this is that the computer isn't solely focusing on playback and may start skipping a little depending on how good the motherboard is and how old the system is. My dual P3 500 Xeon 2m box would probably start choking on this because the sound chip is actually ISA soldered on the motherboard. My dual P2 450 Xeon 1m would probably do ok as the sound chip is PCI soldered on the motherboard. (aren't old linux systems fun?) I'm not sure how a USB DAC would handle it.
A good PCI ethernet card (name brand) would also help. Cheaper cards tend to skimp where they shouldn't forcing the processor to do more work.
|
-=D=-
|
dunndatt said:
Hi Dundatt.
I was also thinking about that parallel loading of tracks while playing back.
Loading the whole CD into RAM seemed to me the best and easiest solution, since this allows also to spindown the harddisk.
That of course can't cover long playlists or ethernet streaming from a server.
Fading smoothly over from one song to another would require , as you say, the second song to be in RAM. I think this can only be managed by the player application itself.
Some kind of watchdog process or timer would have to load the new track at a certain point in time.
Parallel processes will jeopardize my 1sample buffer size that's for sure.
Cheers
soundcheck's script
Hi Soundcheck,
I'm still very happy with the script that plays a tracklist in ecasound.('
')
I tried some figures for -b and found out sound is even getting better with lower figures
with 2 things I'm less happy though.('
')
since my amps have a volume control, i'd better use a fixed volume. Now I have to type "100" each time. (did you know more than 100 is also possible! I woke up all my family typing 1100 in stead of 100).('
')
And than I bought a tft screen for my computer. I has the nasty habbit showing testcolors (al screen black, red, blue, green etc) as long as is sees no computer. Since your scrips disconnects the computer from the screen once playing, my listening room more or less looks (and feels) like a disco. ('
')I did not manage to switch that off, so maybe the script (optional?) should tell the screen to be black.
Should this be easy changes I can do myself ??
regards
Werner
Hi Soundcheck,
I'm still very happy with the script that plays a tracklist in ecasound.('
') I tried some figures for -b and found out sound is even getting better with lower figures
with 2 things I'm less happy though.('
')since my amps have a volume control, i'd better use a fixed volume. Now I have to type "100" each time. (did you know more than 100 is also possible! I woke up all my family typing 1100 in stead of 100).('
')And than I bought a tft screen for my computer. I has the nasty habbit showing testcolors (al screen black, red, blue, green etc) as long as is sees no computer. Since your scrips disconnects the computer from the screen once playing, my listening room more or less looks (and feels) like a disco. ('
')I did not manage to switch that off, so maybe the script (optional?) should tell the screen to be black.Should this be easy changes I can do myself ??
regards
Werner
Re: soundcheck's script
Hi Werner
Sound is getting best if running at lowest buffer sizes!
I'll send you an update. I improved the script again.
The HD will be turned off, if you play full directories.
You won't have any HD access any longer.
And the screen stays dark.
The sound will improve again!
To get rid of the volume control just take out
the "-ea $VOLUME" from the ecasound command in the script.
Cheers
Werner Rem said:Hi Soundcheck,
I'm still very happy with the script that plays a tracklist in ecasound.('
I tried some figures for -b and found out sound is even getting better with lower figures
with 2 things I'm less happy though.('
since my amps have a volume control, i'd better use a fixed volume. Now I have to type "100" each time. (did you know more than 100 is also possible! I woke up all my family typing 1100 in stead of 100).('
And than I bought a tft screen for my computer. I has the nasty habbit showing testcolors (al screen black, red, blue, green etc) as long as is sees no computer. Since your scrips disconnects the computer from the screen once playing, my listening room more or less looks (and feels) like a disco. ('
Should this be easy changes I can do myself ??
regards
Werner
Hi Werner
Sound is getting best if running at lowest buffer sizes!
I'll send you an update. I improved the script again.
The HD will be turned off, if you play full directories.
You won't have any HD access any longer.
And the screen stays dark.
The sound will improve again!
To get rid of the volume control just take out
the "-ea $VOLUME" from the ecasound command in the script.
Cheers
Hello Everyone,
If your looking for a simple Live CD that plays Encrypted DVD's and other Windows media format out of the bag so to speak, give Puppy Linux a try.
Yes it looks like Windows 95-98 is only 80-90 Mb's big but grows on you like a Puppy.
Puppy's User forum will help you like no other and a few forum members have got alot of Linux's Music Apps working.
http://www.murga-linux.com/puppy/
If you want Puppy to look better you can try TEENpup Linux which I created with a bit more eye candy and Apps.
If your looking for a simple Live CD that plays Encrypted DVD's and other Windows media format out of the bag so to speak, give Puppy Linux a try.
Yes it looks like Windows 95-98 is only 80-90 Mb's big but grows on you like a Puppy.
Puppy's User forum will help you like no other and a few forum members have got alot of Linux's Music Apps working.
http://www.murga-linux.com/puppy/
If you want Puppy to look better you can try TEENpup Linux which I created with a bit more eye candy and Apps.
Hi folks.
Newest developments from my side.
I managed to improve the IRQ scheduling and the PC timer precision by 100%, by
using a new kernel patch and changing some timer parameters.
And guess what!
The result is a better sound then ever before. The jitter effects are "almost (of course you never know )" gone.
The stage layer separation is breathtaking, voices and instruments are so clear
and real/natural. Whow.
A bit of background: The standard PC timer under Linux is ticking at 1000Hz or 1ms. That means if an interrupt not belonging to your audio process chain jumps in, which happens in rather random intervals your audio-stream is facing a break. Here the buffering story starts. Of course every process needs certain buffers to cope with the breaks. RME explained very well on their hompage latency-jitter effects related to buffer management. Having many of them - breaks and buffers - in the process will cause unavoidable non-linearities to the stream.
On top some processes and IRQs got a quite high priority. They won't let your audio-process in again. Here the rt-patches come in. In earlier days they were correlated high risks that processes got locked up because of all the tasks running at highest priorities. This has been improved lately.
Solution part1: I introduced the Con Kolivas patch, which makes sure that you get the priority for your realtime process, which is required to avoid non-linearities as much as possible.
And - It works - In my case better than the Molnar patch I used to run before!
Solution part 2: My idea was to increase the scheduling timer frequency - what I've done.
I changed it to 2000Hz. (I'll try higher ones later) I am catching a bit more overhead by slicing the tasks into smaller pieces. (That doesn't really matter, since the audio application is the only major application running on my PC.)
My finding: The data-stream gains obvioulsy linearity a lot. That's what I clearly hear as a result of this tweak.
That'll be it for now. Hope I didn't bore you to death.
Gotta run. Still gotta lot to do!
Cheers
Klaus
Newest developments from my side.
I managed to improve the IRQ scheduling and the PC timer precision by 100%, by
using a new kernel patch and changing some timer parameters.
And guess what!
The result is a better sound then ever before. The jitter effects are "almost (of course you never know
)" gone.The stage layer separation is breathtaking, voices and instruments are so clear
and real/natural. Whow.
A bit of background: The standard PC timer under Linux is ticking at 1000Hz or 1ms. That means if an interrupt not belonging to your audio process chain jumps in, which happens in rather random intervals your audio-stream is facing a break. Here the buffering story starts. Of course every process needs certain buffers to cope with the breaks. RME explained very well on their hompage latency-jitter effects related to buffer management. Having many of them - breaks and buffers - in the process will cause unavoidable non-linearities to the stream.
On top some processes and IRQs got a quite high priority. They won't let your audio-process in again. Here the rt-patches come in. In earlier days they were correlated high risks that processes got locked up because of all the tasks running at highest priorities. This has been improved lately.
Solution part1: I introduced the Con Kolivas patch, which makes sure that you get the priority for your realtime process, which is required to avoid non-linearities as much as possible.
And - It works - In my case better than the Molnar patch I used to run before!
Solution part 2: My idea was to increase the scheduling timer frequency - what I've done.
I changed it to 2000Hz. (I'll try higher ones later) I am catching a bit more overhead by slicing the tasks into smaller pieces. (That doesn't really matter, since the audio application is the only major application running on my PC.)
My finding: The data-stream gains obvioulsy linearity a lot. That's what I clearly hear as a result of this tweak.
That'll be it for now. Hope I didn't bore you to death.
Gotta run. Still gotta lot to do!
Cheers
Klaus
Hi Tom.
I'd be happy to deliver these. Unfortunately I do not own related expensive equipment.
I am also wondering how to measure inside a PC the latency jitter. I havn't seen
very many people done it before. Actually I can't remember one who'd done it.
This I suppose is gonna be quite a difficult undertaking.
There should be some people around here who might be able to check it out for us,
to prove what I am saying. I'd be happy about some support at least!
Would you be able to measure it?
However in the end my audible findings seem to prove my ideas/theories.
To me at least this is more then sufficiant at this stage.
Regarding buffer size: I am running a 1 sample buffer size. Which is by far better than larger buffers if your system can manage it. (If you read this thread you see how I got to this point). No other OS is able to run these low buffer sizes.
With the latest tweaks I improved this already really good setup even further.
Cheers
Klaus
I'd be happy to deliver these. Unfortunately I do not own related expensive equipment.
I am also wondering how to measure inside a PC the latency jitter. I havn't seen
very many people done it before. Actually I can't remember one who'd done it.
This I suppose is gonna be quite a difficult undertaking.
There should be some people around here who might be able to check it out for us,
to prove what I am saying. I'd be happy about some support at least!
Would you be able to measure it?
However in the end my audible findings seem to prove my ideas/theories.
To me at least this is more then sufficiant at this stage.
Regarding buffer size: I am running a 1 sample buffer size. Which is by far better than larger buffers if your system can manage it. (If you read this thread you see how I got to this point). No other OS is able to run these low buffer sizes.
With the latest tweaks I improved this already really good setup even further.
Cheers
Klaus
Since you use a USB dac, which extracts its audio clock from the USB isochronous packets, which are clocked by a CPU interrupt, it is no wonder than optimizing your IRQ timings improve the sound. It is not shakti stones, just logic.
Anyway I still believe you'd be better off with slaving the PC to the DAC and remove the problem
Anyway I still believe you'd be better off with slaving the PC to the DAC and remove the problem
Soundcheck,
Thanks for the update.
Now running xubuntu as my main desktop, slowly trying things. I will patch for low latency shortly, particularly as I use midi, but also to try to confirm your findings.
Can you confirm what advantage the CK patch has over the Molnar patch, even if it is just for your set up? As far as I have read the molnar patch is the more extreme patch for audio with CK's being more focused on the performance of the desktop than anything else. Someone did recommend that both could be used at the same time, but it seemed to me like this could cause conflict (especially since I had to give up on opensuse due to broken features following patching of the kernel and lack of support for the jacklab project - could of course have been the way i did it)
As blackcatsound says, would be nice to see some jitter measurements, but realise this is not possible without the right measuring equipment. I dont actually see how you can say, so definitely, that the sound improvements are indicative of jitter reduction - particularly since it seems sometimes jitter, at some levels, can provide sound which some people actually prefer. Again, the RME article says nothing of audio quality, purely midi timing. Perhaps if you developed a livecd of your setup and full details of your approach one of the guys who has already done jitter measurements of pc systems for some help here - John Swenson in particular has done quite a lot of this as we discussed earlier.
I did note that in the case of the diyparadise Monica ii dac, it is reported that increasing the reclocker frequency by as much as possible (to 80Mhz by diyparadise due to unavailability of higher freqs), sound was improved and that in high freq xo jitter specs are less important. Given the TI usb chips take some timing from the pc, perhaps the increased frequency of the timer is having the same effect here? (this could of course be utter nonsense if the OS timer does not play a part in timing for the chip).
Anyway, measurements or not, its good that your highlighting all thses options for others to try - I doubt my ears are as sensitive as yours though!
Cheers,
Ross
Thanks for the update.
Now running xubuntu as my main desktop, slowly trying things. I will patch for low latency shortly, particularly as I use midi, but also to try to confirm your findings.
Can you confirm what advantage the CK patch has over the Molnar patch, even if it is just for your set up? As far as I have read the molnar patch is the more extreme patch for audio with CK's being more focused on the performance of the desktop than anything else. Someone did recommend that both could be used at the same time, but it seemed to me like this could cause conflict (especially since I had to give up on opensuse due to broken features following patching of the kernel and lack of support for the jacklab project - could of course have been the way i did it)
As blackcatsound says, would be nice to see some jitter measurements, but realise this is not possible without the right measuring equipment. I dont actually see how you can say, so definitely, that the sound improvements are indicative of jitter reduction - particularly since it seems sometimes jitter, at some levels, can provide sound which some people actually prefer. Again, the RME article says nothing of audio quality, purely midi timing. Perhaps if you developed a livecd of your setup and full details of your approach one of the guys who has already done jitter measurements of pc systems for some help here - John Swenson in particular has done quite a lot of this as we discussed earlier.
I did note that in the case of the diyparadise Monica ii dac, it is reported that increasing the reclocker frequency by as much as possible (to 80Mhz by diyparadise due to unavailability of higher freqs), sound was improved and that in high freq xo jitter specs are less important. Given the TI usb chips take some timing from the pc, perhaps the increased frequency of the timer is having the same effect here? (this could of course be utter nonsense if the OS timer does not play a part in timing for the chip).
Anyway, measurements or not, its good that your highlighting all thses options for others to try - I doubt my ears are as sensitive as yours though!
Cheers,
Ross
peufeu said:Since you use a USB dac, which extracts its audio clock from the USB isochronous packets, which are clocked by a CPU interrupt, it is no wonder than optimizing your IRQ timings improve the sound. It is not shakti stones, just logic.
Anyway I still believe you'd be better off with slaving the PC to the DAC and remove the problem
Hi peufeu.
I guess, you know that I am pretty well aware of the master/slave clocking issue.
However.
When listening to my current sound, there is not very much inside me, telling me to go for more - at much more effort - and the question in my head if it'll be better in the end.
All solutions are compromised solutions at a certain stage, that's for sure.
(Of course I havn't heard your ethernet solution. But we discussed this issue earlier.)
And when talking other master/slave setups, you actually never know what happens on the way from your file to your digital sound interface or soundcard. (You most probably generate a lot of mess before your stream reaches the soundcard and most soundcards won't be able to do anything about it)
I pretty much believe that my findings are not waste of time and also applicable for other setups. You might even try it in your environment.
Cheers
\Klaus
rossco_50 said:
Hi Ross.
The RME article I liked very much due to the way the explained the buffer management and the related latency jitter. That's why I bring it up.
Since nobody can give me a more solid explanation, I bet on this issue ( in the context of non-linear IRQ handling/scheduling ) as a plausible cause for the sound degredation.
I read some of John Swensons reports. As far as I recall they were much
more downstream related. I can't recall any measurements inside the PC.
CK introduced a new staircase scheduler the other day, together with the opportunity to increase the timer frequency its my choice. My sound definately improved after changing from Ingo Molnar to CK.
(BTW I don't run X desktops, while playing audio any longer!)
Ingo Molnar will soon launch a new version of his patch, which is supposed to catch up again.
When it comes to your ears! Even my wife hears the difference!
I bet you'd beable to hear it. (Of course it'll depend on your overall chain, if these differences are audible or not! There is a slight chance that the improvements might disapper in the overall jitter and noise level of your system.)
Cheers
\Klaus
Surely if there are improvements to be measured these can be measured downstream at the DAC? I dont think there is any question that you have made a more efficient PC OS and that the data streams are as intact as they can be (or close to it), if you had the relevant test equipment you should be able to atleast measure differences in the audio between default settings and your tinkerings at the I2S output (if not prove that the signal quality has improved).
I find it difficult to keep up with these patches, may not be worthwhile rushing to try either of these until this next signficant release is made.
cheers.
I find it difficult to keep up with these patches, may not be worthwhile rushing to try either of these until this next signficant release is made.
cheers.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.