I vaguely remember info about using real time patched kernels for audio work in the old Sidux WIKI and wanted to know what the situation is now with aptosid and the latest kernels.

I'm interested in trying to squeeze the last bit of goodness out of digital audio playback while using aptosid. My favoured player is MPD and I can init 3 to drop down to a minimal load and use ncmpcpp as the client, or use sonata if the desktop is running. I can either us a USB connection to my external DAC or Spdif from my envy24ht based s/card.

I'm interested in trying to squeeze the last bit of goodness out of digital audio playback while using aptosid.

I could be mistaken, but playback doesn't sound like a usecase for realtime kernels. In general, applications need to be specialized for it…

I mean, there is the enormous time-critical problem you want to solve in playback - in opposition to recording and mixing yourself.

And just to be sure: A real-time kernel has NO positive performance effects in general -- it might even have the opposite as the point of realtime is that an application can be so 'unnice' in terms of cpu-sheduling that other application doesn't get a share of the cpu anymore…

_________________MfG. DonKult
"I never make stupid mistakes. Only very, very clever ones." ~ The Doctor

is irrelevant to audio playback under Linux? That attempting to tune irq priorities or increasing the audio thread priorities to Real-Time or setting cpu inifinty is all a waste of time if all you are dealing with is audio playback?

I don't know if it is useful or not, others elsewhere on the web who deal with Linux audio seem to think it might matter.

I'd like to know what is possilbe within aptosid, try software tweaks and decide for myslef if it's a waste of time.

DeepDayze

Post subject:Posted: 12.08.2011, 19:11

Joined: 2010-09-11
Posts: 616
Location: USA
Status: Offline

latencies are more relevant to recording audio and the real use case for RT kernels are for high-end audio recording and processing. Playback is not quite as critical unless you are an audiophile

krisbee

Post subject:Posted: 13.08.2011, 06:33

Joined: 2011-04-25
Posts: 49
Location: London
Status: Offline

DeepDayze wrote:

latencies are more relevant to recording audio and the real use case for RT kernels are for high-end audio recording and processing. Playback is not quite as critical unless you are an audiophile

OK, I understand playback alone does not require RT kernels but I was interested to see if I could hear any differences by applying the ideas of low latecny audio.

Apart from it's literal meaning, a lover of music, I have never been exactly sure what an "audiophile" is. Certainly there are many who appear to be obsessed with the pursuit of what in their ears iis audio nirvana. But if a few software tweaks might make an audible difference, why not try them?

It will be simple enough to do this, and hear for myself, via another route.

IIUC, low-latency is only needed for recording (and more importantly for overdubbing), not listening. Latency is merely the delay between the computer processing the sound file and the data coming out of your speakers. Who cares if you press PLAY and the music takes 30ms to begin? Such tiny delays are mostly imperceptible, and equivalent to sitting 30ft from a musician and waiting for the sound waves to arrive through the air (sound travels about 1ft/ms). I'm pretty sure you wouldn't insist on sitting with your ear pressed up against the singer's mouth at a gig! And if so, how would the rest of the band feel? I play in a large drumming group where sometimes 25 people are spread out over a large stage, so faraway players are going to be out of time by 50ms or so. This happens with any large orchestra.

The only people who care about latency are those trying to play/overdub in time with the music already recorded. It gets really confusing trying to play a (soft)synth at a high-latency setting when the notes you play don't reach your brain until a moment later! Like trying to sing a duet with someone down a mobile phone line.

I'm no expert, but I would have thought that listeners may instead benefit from slightly higher latencies, ensuring their computer has no problem keeping up with playback, much like some portable CD players used to read data into a buffer to prevent tracks skipping by allowing errors to be re-read.

krisbee

Post subject:Posted: 16.08.2011, 10:32

Joined: 2011-04-25
Posts: 49
Location: London
Status: Offline

If, in simple terms, latency equates to delay, then of course I accept everything you say. Perhaps low-latency wasn't such a good title, as my initial web refs show ways in which to attempt to prioritise audio processes, interrutps etc.

To take you're exmaple, listening live to musicians 30ft away is fine if the "delay" for the sound to travel to your ear is consistent. If this "delay" was to vary randomly then might it not affect what you hear? In the same why, if computer audio playback suffers random fluctuations in timing due to nature of the system (process, interrupts etc.) may this not have some bearing on audio playback? Of course, whether this is at all audilbe or not is open to question and the "buffers" in use may iron all this out anyway.

I believe there is a "threadirqs" boot option that can be used with the latest kernels. Using this in conjunction with the "rtirq-init" script might go some way to achieving what is in those web refs. A pointless exercise perhaps, buy easy to try.

CaesarTjalbo

Post subject:Posted: 17.08.2011, 13:26

Joined: 2010-09-13
Posts: 96
Location: Enschede
Status: Offline

krisbee wrote:

To take you're exmaple, listening live to musicians 30ft away is fine if the "delay" for the sound to travel to your ear is consistent. If this "delay" was to vary randomly then might it not affect what you hear?

It does affect what you hear. Good speakers for a crowd know to slow down their speech because sound has a tendency to 'bunch up'. In order to get the message through, you have to speak a bit more slowly for the people at the back and the sides to be able to separate words more easily.

For a technical side of this, I imagine (but don't know if it occurs) that varying latency on playback is an issue for multi-channel surround setups.

krisbee wrote:

buy easy to try.

Not at all. Measuring is done by tools, not by hearing. Picking the tools and setting up a testbed is probably far from easy (or cheap).

What's your frame of reference? Your dedicated audio-setup? And what are you going to do if you measure that to have a bigger/less consistent latency? Throw out your CD-player?

Do you know what you're measuring? I.e. are you measuring the latency on kernel level, driver level, soundchip, wiring, soundstack (Jack, ALSA, PulseAudio, Phonon, OSS)? How are you going to find out?

krisbee wrote:

A pointless exercise perhaps,

No, it might be interesting and educational. Hard though. Basically you want to test latency and latency alone, so you'd have to try to keep most other parameters unchanged.

Playback doesn't seem to be the most suitable way of testing it. You want to record sound from a few different sources onto 1 track with a 'normal' kernel and then repeat it with a real-time kernel. How well does Jack work on a non-rt kernel? I don't know if Jack was made for that but at least it seems it can be used that way.

If all goes as expected you'll measure a difference and you're able to conclude that real-time low-latency kernels deserve a place under the sun. Or maybe you're able to debunk yet another hi-fi myth, who knows.

DeepDayze

Post subject:Posted: 17.08.2011, 14:22

Joined: 2010-09-11
Posts: 616
Location: USA
Status: Offline

RT kernels are also useful for any time-critical functions such as process control too, not just audio/video recording

slh

Post subject:Posted: 17.08.2011, 16:45

Joined: 2010-08-25
Posts: 949

Status: Offline

CaesarTjalbo wrote:

For a technical side of this, I imagine (but don't know if it occurs) that varying latency on playback is an issue for multi-channel surround setups.

Your imagination is wrong for multi-channel playback, all channels are affected alike and synchronized, -rt does absolutely nothing for playback or any kind of media consumers and only slows down normal operations.

The only domain where -rt can make a difference, besides automation with mandatory maximum response time guarantees (only soft real time is possible with generic operating systems anyways), is audio mastering (mixing many (live-) sources, dubbing, etc.), audio playback, watching videos doing video cutting does not profit from -rt at all. On top of that, the normal linux kernel has a improved a lot in this regard (we keep an eye on low latency configurations, as long as it doesn't hurt normal operation) over the last 5+ years, which makes a dedicated -rt kernel obsolete (at least optional) in many cases.

dpt

Post subject:Posted: 17.08.2011, 18:09

Joined: 2010-09-11
Posts: 281
Location: New Delhi
Status: Offline

I have never seen any problem in sound quality. I used to build hi-fi audio systems ages back(obviously analog),
and I am also perhaps some sort of audiophile.
There of course, may be many more-perfect audiophiles. Maybe they do not work for Linux.

dpt

_________________In a lunatic asylum, everyone thinks that he is the doctor.

CaesarTjalbo

Post subject:Posted: 17.08.2011, 22:46

Joined: 2010-09-13
Posts: 96
Location: Enschede
Status: Offline

slh wrote:

Your imagination is wrong for multi-channel playback, all channels are affected alike and synchronized

I suspected as much. Note that I didn't say an rt-kernel is needed for multi-channel playback.

slh wrote:

On top of that, the normal linux kernel has a improved a lot in this regard (we keep an eye on low latency configurations, as long as it doesn't hurt normal operation) over the last 5+ years, which makes a dedicated -rt kernel obsolete (at least optional) in many cases.

That was actually the impression I'd gotten from following kernel development, albeit on a 'for dummies' level.

kmceng

Post subject:Posted: 19.08.2011, 14:59

Joined: 2011-08-12
Posts: 10
Location: new york
Status: Offline

Just my 2-cents:
If you haven't already, you may want to look at the studio64 website. They've been doing RT linux and audio for years and may have much info.

I did audio with it several years ago and found it strong in many ways.