Re: [LAU] rtirq

On Mon, 16 Mar 2015, Joakim Hernberg wrote:

> On Sun, 15 Mar 2015 08:08:23 -0700 (PDT)
> Len Ovens <len@email-addr-hidden> 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
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user