On Sat, 25 Nov 2017 13:55:38 +0000, Fons Adriaensen wrote: Hi Fons, no neutral measurements, just my individual mixing experiences. I always noticed audible noise comparable, if not more annoying noise, to noise I experienced for good analog recordings, still too much for my taste. I couldn't find an alternative solution yet. When I used Cubase for testing purpose on Windows around a decade ago, it shipped with a dithering plugin. I don't remember it's name, but after googling I guess it was https://steinberg.help/cubase_plugin_reference/v9/en/_shared/topics/plug_re… . I still remember that "dither noise is gated during silent passages" wasn't the only benefit, it was always nearly inaudible, at least not as loud as noise, I experienced with good analog tape recordings, while my experiences with jack2 couldn't hold a candle to this plugin. Regards, Ralf

Peter <list-uRjC9i54a0HBwHGg3TQQPgC/G2K4zDHf(a)public.gmane.org> writes: 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

I would mount the drive with noatime but your drive might be broken, even if the output of sudo smartctl -A /dev/sdX or sudo smartctl -a /dev/sdX seems to be ok. I agree with David regarding the advantage of a SSD. I own two _inexpensive_ TOSHIBA-TL100 (OCZ TL100) 240 GB. Free as in beer Linux software for OCZ SSDs is provided by the Arch User Repository, it's useful, since the output of smartctl for those SSDs is cryptic. I disagree on the statement that increasing the frames has got no negative impact. It could affect MIDI jitter, when recording MIDI tracks with external MIDI equipment to audio tracks. -- $ pacman -Q linux{,-rt{,-cornflower,-pussytoes}}|awk '{print $2}' 4.14-2 4.13.13_rt5-1 4.11.12_rt16-1 4.14_rt1-1

On Thu, 7 Dec 2017 00:14:01 +0100 (CET), Jeanette C. wrote: Hi, I don't know. They still will be faster than SATA 2 HDDs. However, when I migrated from SATA 2 to SATA 3 I was surprised about the quick startup, it's more or less power on = booted and I'm still amazed about the increased virtualbox performance, my Windows 7 guest became faster than the children's "offener Ganztag" Windows 7 installs on bare metal. Unlikely an issue for you, but the known GTK app performance issues, such as the visible black box when widgets are established, have nothing to do with the disk drives. I don't know, but as already mentioned by an earlier reply to the former subject, I decided to buy OCZ SSDs, because they were the cheapest that time and the AUR provide packages for OCZ tools, ocz-ssd-utility, oczclout and ocztoolbox, see https://aur.archlinux.org/packages/?O=0&K=ocz . My drives are neither supported by clout (the CLI tool to e.g. show smart attributes), nor by ocztoolbox (a GUI). Fortunately ocz-ssd-utility (another GUI) does the job, since smartctl is quite useless: [rocketmouse@archlinux ~]$ sudo smartctl -A /dev/sda | grep Unknown 167 Unknown_Attribute 0x0022 100 100 000 Old_age Always - 0 168 Unknown_Attribute 0x0012 100 100 000 Old_age Always - 0 169 Unknown_Attribute 0x0003 100 100 010 Pre-fail Always - 0 173 Unknown_Attribute 0x0012 180 180 000 Old_age Always - 0 Actually the GUI explains the "Unknown_Attributes". 167 SSD Protect Mode 168 SATA PHY Error Count 169 Bad Block Count 173 Erase Count Regards, Ralf

My DAW computer is about 6 years old and was supplied with one Intel SSD and one Samsung one - both 128G. I haven't taken any special measures with it. It's in daily use, sometimes quite heavy, and so far neither drive has shown any kind of problem. My 'office' machine has a single 250G Intel SSD and is about 2 years old, and again has no special measures taken and is in daily use. I have a samsung 250G USB SSD that I use for backup and some synchronisation/transfers... as above. -- Will J Godfrey http://www.musically.me.uk Say you have a poem and I have a tune. Exchange them and we can both have a poem, a tune, and a song.

Dear Jeanette, out of curiosity I created a RAM-disk sudo mount -t tmpfs -o size=10G tmpfs RAM and recorded to that one. As a result, I couldn't record 32 channel at 48kHz and a buffer of 128. At a buffer of 256 it ran without any xruns, however, in that case, storing on hard disk creates an XRun only once at a while. So I'm not sure, whether a SSD would improve much. at least you could make a test recording to a RAM disk. -> jackd: v0.125.0 (-R --timeout 4500 -d alsa -C multi_capture -P multi_playback -r 48000 -p 256 -z shaped) Note, I made my test simply using ardour5 and jackd. Best regards, Peter

Nov 30 2017, Peter has written: Dear Peter, ... No, it's an internal S-Ata drive, apparently a SAMSUNG HD154UI. For cached reads this averages around 1200 MB/Sec, for buffered reads around 108 MB/Sec. I didn't find an option to test the writing speed. As a write test, I tried this: dd if=/dev/zero of=out.file bs=1M count=100 with a result of around 560MB/Sec I could, but I already have it a period size of 256. At 512 I started to get a noticeable delay. With cards that can potentially go down to 64 samples, I feel a - perhaps unreasonable - hesitation to set the period higher. Is this very unreasonable? ... Best wishes, Jeanette -------- * website: http://juliencoder.de - for summer is a state of sound * SoundCloud: https://soundcloud.com/jeanette_c With you I get so high Lost in the crystal sky You are this melody That's where you take me <3 (Britney Spears)

Nov 30 2017, Peter has written: I just tried a JACK period size of 1024, with the result of no xruns, but also much too much latency. Since I have to monitor everything through my soundcard and also receive guidance from previously recorded tracks that will sadly be not a feasible solution. ... Ah and there would be an additional snag. :) But for mixing a higher delay is not a problem at all. Due to my recording environment and the fact that I do studio work only, I do not work very "live". ... -------- * website: http://juliencoder.de - for summer is a state of sound * SoundCloud: https://soundcloud.com/jeanette_c With you I get so high Lost in the crystal sky You are this melody That's where you take me <3 (Britney Spears)

"Jeanette C." &lt;julien-3g/GUrBLTNIb1SvskN2V4Q(a)public.gmane.org&gt; writes: Well, the problem is not as much your cards but the disk I/O. Getting more buffers will already help (-n 3 instead of the default -n 2). You can try improving this problem by using rtirq to distribute realtime priorities: do you already use threaded irqs? -- David Kastrup