Non Real-Time Audio Production?

[dArAzAc]

I'm wondering why any musician would use a distribution such as ArtistX [http://www.artistx.org/site2/] which offers loads of audio production tools, and yet has no real-time kernel or RT capabilities. With a kernel that is generic and unmodified, are people able to get RT comparable performance in spite of this? I could see how this is possible if there are minimal background processes, and only one application at a time-- but on Linux I've always at least 3 different audio applications going at any given time.

Is this realistically possible? After all, many people use Windows for audio production-- and I (could be wrong) don't think Windows has any real-time capabilities.

[raboof]

I'm wondering why any musician would use a distribution such as ArtistX [http://www.artistx.org/site2/] which offers loads of audio production tools, and yet has no real-time kernel or RT capabilities.

Never heard of it before, not sure if it's much-used

With a kernel that is generic and unmodified, are people able to get RT comparable performance in spite of this?

I see they're shipping quite a recent kernel. The realtime patches are steadily being merged into the mainline kernel - I found the 'normal' non-RT Debian Testing kernel to be quite comparable the the UbuntuStudio/64Studio realtime kernel for simple MIDI/softsynth stuff - the non-RT Ubuntu kernel was much worse.

( http://lwn.net has a nice article about this - I don't have the free link handy, but it should become available to non-subscribers in a week or so )

[Havoc]

I never used a RT kernel and never had issues with it. It depends on what you actually do, not if you run audio or not.

The RT kernel is useful if you playback sound from the application and record a new track alongside it. Because then the latency will introduce a shift between the original audio and the new recorded track. And that shift will be larger if the latency is larger.

But if -like me- the only thing you do is transcription of recordings from tape/vinyl/dat to pc and then edit those recordings, then latency isn't an issue. I get something in the 40ms range from normal kernels without any tweaking.

[dArAzAc]

Interesting, I wonder how long before the generic kernel is capable of real-time processing.

[Havoc]

RT is a very subjective item. It just means that the processing of a chunk of data has to be completed before the next arrives and that any action that needs to be taken is done so. You could imagine situations where RT mens "next week".

[brummer]

RT is a very subjective item. It just means that the processing of a chunk of data has to be completed before the next arrives and that any action that needs to be taken is done so.

Not realy, it means that you could give a higher priority for CPU sheduling. A positive side effect is that you could leave open all your non audio stuff when record a new session, for example.

Didn't a chunk of data must complet processed anyway, befor process the next ? rt or not, that didn't make a diff on that. I guess that, when you don't run in rt mode, simply all other audio aplications wait, up to all chunks are ready, then start the next one. That's not possible when record live (rt), then a chunk must be done in time, isn't it ready, it will skipt (xrun). So next week play a other band on the same stage, no time to lose.

[dArAzAc]

To my understanding realtime also means that every application/process has equal priority. That way, when you're running JACK, Ardour, Rosegarden, and ZynAddSubFX at the same time one application can't get ahead or behind another-- which would create serious problems with audio production in that manner. I've experienced this personally which is why I think that, if you only run one application at a time, there is no need for a real-time kernel.

[raboof]

It just means that the processing of a chunk of data has to be completed before the next arrives and that any action that needs to be taken is done so.

it means that you could give a higher priority for CPU sheduling

realtime also means that every application/process has equal priority

'real-time' has become a bit of a fuzzy term. Fundamentally, it just means that the time it takes to generate a response to an event matters: there's some timing constraint that should be taken into account. As Havoc mentions, this does not really specify how small these timing constraints would be, but 'improving real-time performance' usually means being able to handle tighter timing constraints.

If some processes do have timing constraints and some don't, it is useful to extend the scheduler to schedule processes with timing constraints with higher priority compared to processes without such restrictions.

Another big part of 'realtime' in Linux/OS world is pre-emption: suppose a non-realtime thread is busy doing something, and a realtime thread becomes available. If the non-realtime thread continues for too long, we risk missing the deadline for the realtime thread. Because of that, we want to be able to kick out the non-realtime thread in favour of the realtime thread. Kicking and re-starting the non-realtime thread will probable reduce performance a bit, but we gladly give that up to make our realtime threads meet their deadlines at the expense of the non-realtime threads.

Another area where a lot of work is done to improve realtime performance is concurrency/locking: whenever threads lock resources, they risk blocking a realtime thread. Therefore, it is desirable that as few locks are held as possible, and locks are held as shortly as possible. This, too, can help meeting our realtime thread's deadlines, so this, too, can be seen as 'realtime work'.

It's a broad area with lots of different aspects. To confuse matters more, 'real-time' is also used when people just mean 'interactive' or very generally 'with low latency'.

[brummer]

'real-time' has become a bit of a fuzzy term. Fundamentally, it just means that the time it takes to generate a response to an event matters: there's some timing constraint that should be taken into account. As Havoc mentions, this does not really specify how small these timing constraints would be, but 'improving real-time performance' usually means being able to handle tighter timing constraints.

The size from the "transportet" data is fixed per time in rt mode. No matter how small or big you set the frame size, you will always get ~24 Samples for 1ms. If a application isn't able to send/recive this amount, it will be scipt/kill remove from the data flow.