[LAU] Massive Xruns during recording

[David Kastrup]

Peter <list-uRjC9i54a0HBwHGg3TQQPgC/G2K4zDHf at public.gmane.org> writes:

> Dear Jeanette,
>
> Am 30.11.2017 um 16:54 schrieb Jeanette C.:
>> Hey hey,
>> after further analysis, I find that my hard drive seems to be the
>> problem. I can't write fast enough. Playback of multiple tracks is
>> no issue (ca. 10 stereo tracks, 32bit, 48kHz), but 5 stereo tracks,
>> even from an external source, start to generate hiccoughs.
>>
>> Can it be that the drive is really that bad, or is there a parameter
>> to tune, so this could be improved?
>
> this looks indeed pretty slow, is it an external usb-2 drive?
> You may perform a simple check:
>
> sudo hdparm -tT /dev/sda
>
> Replace sda with your device.
>
> If your are just recording, can you increase the buffer length in jack?
> I was recently recording 32 mono channels and got initially lots of
> xruns in ardour,
> which disappeared after increasing the buffer size in jack.

Well, Jeannette stated that she was replaying 4 stereo tracks at the
same time she was recording five.  With a buffer size of 256 samples
(using ALSA, this implies a default of only 2 buffers).  This kind of
double-duty regarding playback/record is more problematic for rotating
disks (and this is a 5400 rpm disk) than it would be for solid-state
drives.  Playing with the disk parameters (in particular to avoid the
less time-critical bulk writes delaying the playback reads) might help.

Frankly, I'd consider recording to SDHC card (they are quite cheaper
than a SSD drive which would be the better option).

But of course, increasing buffer size might be all that is needed.  The
only reason for smaller buffer size is real-time monitoring and/or
real-time effects.  Monitoring might be doable in analog (personally, I
am using a mixer with recording interface in order to be able to do
that).  Multitracking as such does not need small buffers: the delays
can be properly compensated by latency management.

-- 
David Kastrup