[LAU] rtirq

[Len Ovens]

On Mon, 16 Mar 2015, Joakim Hernberg wrote:

> On Sun, 15 Mar 2015 08:08:23 -0700 (PDT)
> Len Ovens <len at ovenwerks.net> wrote:
>
>> The reason I asked, is from reading about people using three drives
>> for audio: OS, sample data, and audio streaming (record). And though
>> I have not had any problems with disk writes (even when I was using
>> only 1GB of ram and a PATA drive) I do tend to simpler things of
>> fewer tracks and no synth. For the most part, I would think any OS
>> parts would be sitting in memory anyway.
>
> I may be asymptomatic as I run reaper with wine/wineasio/jack/linux-rt.
> But I can't do (lowlatency) xrun free audio if the media files resides
> on my home, I have to use a separate partition for it.  Normally mixing
> about 20-30 tracks either from wavepack or wave media.  I did try all
> the disk i/o schedulers, even setting reaper as realtime disk i/o class
> and highest priority using ionice.  Mind you this is using rust for
> media.  No idea if the problem would persist with ssd...

I don't think it is possible to set an application to have faster access 
to a physical drive. Making the pysical writing as fast as possible is the 
only way to do that. The application writes to memory buffer when it does 
a disk write, which can be very fast and prioritized, but the OS handles 
the actual writing the buffer to the HW. SSD may help, but even those have 
a one way link, that is they can only read or write at any one time. So if 
already written tracks have made it to disk and have been over written in 
memory, they have to be streamed back in as they are played. If the OS 
happens to be writing to the same disk at the time, there is waiting to be 
done and there may be dropouts/underruns in the playback audio. Two drives 
allows simultanious read and write. I think if ram is big enough and 
swappiness is low enough, a third drive for the OS is not needed. If ram 
is large enough, there will be no writing needed and the playback will be 
in memory too. Once an application writes data to a buffer... That is, it 
does a sw disk write, the data is in memory, but as far as the application 
knows it is on disk.

making a spinning disk read/write faster can be done, aside from a faster 
turning speed, by only using a partition one the outer half of the drive 
and/or by using more than one drive in the right raid configuration so 
that one file is written across all the drives at once.

considering the cost of SSDs and the unreliability of faster disks, I 
think SSDs are becoming the way to go for almost everything. I would not 
use one for swap, but then I would not use swap at all when doing audio 
except as a safety net in case of an OOM event, the take would be lost but 
not the project. That is, I would replace swap with more ram.

Really, the average life of newer drives has become dismal. Two years 
seems to be pretty common where 5 to 10 years used to be common. SSDs 
should last over 10 years even with a lot of writing and are supposed to 
be able to switch to read only once their writes are used up... or this 
can be done manually in fstab if the user feels that time is close.

--
Len Ovens
www.ovenwerks.net