Playback cuts out periodically in ALSA (Linux)

St_John_from_Des_Moi · September 22, 2021, 2:40pm

Good morning, everyone! I did search the forum before creating this, and couldn’t find anything that quite reflects what I’m experiencing. But I’m also notoriously bad at searches, so if this has been brought to the forum before, I’m fine with being linked to it and having this thread closed.

SHORT VERSION (all you need to read if this tells you everything you need to know): I have periodic and semi-random cut-outs in audio during playback (monitoring) in Ardour in Ubuntu Studio Linux using ALSA. No other audio sources experience this cut-out (including Audacity), and audio files exported by Ardour are likewise unimpacted - only playback during monitoring / production. Also, I am using this set up on two different computers, and only the one computer experiences the issue.

If this is all the info you need, please feel free to stop reading here. Otherwise, see below for more info!

MORE INFO (aka LONG VERSION): I’m using Linux (Ubuntu Studio 21.04) on two different computers:

a “DIY” Gaming PC (salient specs: Kaby Lake i5 7600K, 16GB DDR4, 256GB M.2, GTX1070 - audio outputting via HDMI through the GTX1070), video output 3820x2160 60hz 1:1 resolution scale Chroma 4:4:4 into a Sony X800D 4K TV.
a Dell Latitude 7480 laptop (salient specs: Kaby Lake mobile i7 7600U, 16GB DDR(?), 512GB M.2, Intel HD620 - audio outputting via various sources depending on context, video output when hooked to the Sony X800D the same as the Gaming PC except only 30hz, native laptop display 1440p 60hz touchscreen).

I am -ONLY- experiencing the audio cutouts on the Gaming PC, and never ever on the laptop. Also, it is -ONLY- happening in Ardour, and only during playback (monitoring) / production. Never in the stuff it exports.

The settings in Ardour are the same on both computers: ALSA, All available channels, etc. Both computers have pulseaudio installed, and both computers have JACK installed. To the best of my awareness, the ONLY differences between the two computers is that the HDMI (through which the over all PC audio is routed) on the Gaming PC is running through the GPU. I am aware of no other differences in set up between them, and again, the cutouts impact literally absolutely nothing else on the device, no other audio sources cut out. Only playback in Ardour during production.

It’s a “nuisance” rather than a “crisis”, because, again, it doesn’t impact the final exported audio files, and because the cutout never lasts for more than two to three seconds at a time, and often only occur once every few minutes or so. If the cutout happens at a time where I REALLY need to hear what’s happening (at a transition for instance), I can always pause playback for a few seconds and then resume, and I have sound again, and if it’s at a time where I don’t really need to hear what’s happening (such as in the middle of a piece of music), then I can simply wait it out and let it run.

Does anyone have any ideas? Again, this bug doesn’t “break my process”, but it sure is annoying, and I’d love to learn a way to make it go away.

Also, I realize that I could always circumvent the problem simply by moving production work back to the laptop, but I really want to do the majority of my production on the big rig from now on, so I don’t have to mess with temporary set ups that I have to hook and unhook, etc. Plus, outside of graphics (where it is HUGELY more powerful than my laptop), and boot drive storage (which is only half as big), my gaming PC is a little bit more powerful, and outputs video at 60Hz, which is not only nicer on the eyes but also easier to produce on than 30Hz.

So hopefully there’ll be a fix for the big rig!

Thank you so very much in advance for all the help!

Cheers!

x42 · September 22, 2021, 5:10pm

This is not a realistic option for low latency pro-audio work.
Ideally get a dedicated soundcard.

This is normal. Export happens offline (not realtime): Ardour processes as fast as possible, as slow as necessary.

What settings do you use? sample-rate, buffersize – in Ardour menu > Window > Audio/MIDI Setup.

For HDMI you need at least 4096 samples buffers, or alternatively use Ardour’s pulseaudio backend (but that is playback only).

Have you set up realtime scheduling? In Menu > Window > Log. check if there is perhaps a warning “AlsaAudioBackend: cannot acquire realtime permissions.”.

I expect that if you use a USB soundcard, the issue will go away. Except there may be factors still, see Ardour Manual: the right computer system for digital audio.

St_John_from_Des_Moi · September 22, 2021, 5:44pm

Thank you for getting back to me!

If I’m intending to do the lion’s share of future production work on the big rig (especially if multi-track music production is planned for somewhere down the road like it is), then getting a dedicated sound card may be well worth my time! So I’ll look into that. Do you have a recommended card I should look into?

In the meanwhile, as for the rest of what you had to say, the first thing I’ll try is kicking the samples buffers up to 4096 next time I start it. I’m running 1024 right now. But since I’m actively in the middle of production as I type this, I don’t want to interrupt the flow to make the change right this minute (In other words, I’ll just live with it for the remainder of this session, and hope for better next time). The nice thing is that I’m not doing a complex 32 track piece of music, but rather, am doing a video game music podcast episode with two tracks for music (alternating pieces of music between the tracks), and one for talking. So, the latency concern on this kind of production complexity level is very remote, and hasn’t really come to bite me thus far in my now nearly 5yrs of podcast production work (almost the entirety of which happening over HDMI) - though only the past year and half has been done through Ardour on Linux. Before that, it was GarageBand in macOS. And this is actually the first big production I’m doing on the big rig. The past year and a half has all been the laptop.

The thing that confuses me concerning the whole “HDMI as the source of the problem” scenario which you’ve proposed is that usually when I would be doing production on the laptop, and I’d have it hooked up to the Sony (the condition in which I did the vast majority of my production on the laptop), I’d also be running audio through HDMI, but never had these same problems. So, unless the added step of going from motherboard through [presumably] PCIe into the GPU and then out through HDMI (as opposed to using the HDMI built into the motherboard itself) is where you believe the bottleneck is occurring, then I struggle to see HDMI as the source of my problem - as [at least apparently] disproved by the HDMI on my laptop not manifesting the same problem - especially when the HDMI on the laptop is only HDMI 1.4, where the HDMI on the GPU is the faster HDMI 2.0. Granted, I cannot recall what the buffer setting was set to on the laptop. Maybe it was 4096, and maybe that was the difference maker…who knows?

Another clue (and this may well tell us everything right here): when starting an Ardour session on the big rig, I get a popup warning me about potentially running out of memory. I can’t remember precisely what it says, and I don’t think I can summon it again without closing out my current production session. But I do not recall ever seeing this message on the laptop. The more I think about it, the more I suspect this may be the most important clue. And in addition to the audio cutting out for a few seconds at a time every few minutes (while the playhead keeps moving), if I jump the playhead around a lot in a short amount of time (like when I’m level checking multiple pieces of music), sometimes, Ardour will change from a “play” to “stop” condition on its own for a second or two before resuming on its own. I also do not recall having ever experienced this lurch on the laptop, and it further suggests a memory issue.

If that memory issue is simply because I only have the buffer set to 1024, well then no biggie! I’ll have that fixed the next time I boot up Ardour and should be set to go. But if it’s something deeper, then that too is confusing, because both the desktop and the laptop have 16GB of memory. Actually, in the grand scheme, the desktop has more memory, because it’s 16GB dedicated system memory plus 8GB dedicated video memory on the GPU vs 16GB total memory shared between system and video on the laptop. So, if there’s a memory issue on the desktop that’s not happening on the laptop, and if buffer size settings in Ardour are not the problem, then I can only conclude that there must be some kind of memory sinkhole happening on the desktop and that would be troubling indeed. Then again, the fact that it’s -ONLY- happening in Ardour during playback indicates that it is probably buffer setting related and that making that one fix may resolve everything for me.

I’ll reply again once I’ve had a chance to finish up my current production, save and exit, and re-enter the program with the proposed changes. I’ll also write down the exact wording of the memory issue alert should it still appear after upping the buffer, so we can get a better idea what’s going on there.

In the meanwhile, thank you again so much for your help!

x42 · September 22, 2021, 7:40pm

It may be counter-intuitive, but often older, slower systems are more reliable for low latency audio. One reason for that is that recent systems perform aggressive power-saving and force the system into idle. Also periodic health checks can hog the system for a long time (msec), and break real-time processing constraints.

you could check with watch -d -n 2 cat /proc/interrupts and see if you can correlate any of the IRQs (Thermal event, Machine check …) with the drop outs.

Also try to disable WIFI (sometimes wifi scanning hogs the bus).

Since you say it is periodic every minute or so, that could also be a likely candidate.

Top-right in Ardour’s GUI, there is DSP load indicator and in parentheses after it, a drop-out (xrun) counter. Is that non-zero? Here (Thinkpad X1) when using HDMI there are constant x-runs even at long latency, while using onboad soundcard or USB devices it works reliably down to a few msec.

Depends what you need. How many channels input + output? Do you want a separate, dedicated headphone output? What microphone(s) do you use to record the podcast (do you need phantom power)? Do you have a unused USB port (not behind a hub)? What is your budget?

A reasonable entry-level product is around $100 search for “Scarlett 2i2” or “Steinberg UR22” and " Presonus AudioBox" and then follow the “you may also like” trail

All “USB class compliant” devices will work directly on Linux. If a device works on iOS (no drivers needed) it will also work on Linux.

likely “Cannot LOCK memory”.

This is to prevent the system from swapping out memory to disk (which is slow and can cause dropouts). On most modern machines with sufficient RAM this is usually a non-issue.

St_John_from_Des_Moi · September 22, 2021, 8:10pm

That IS interesting, the counterintuitive superiority of HDMI 1.4 over 2.0 for low latency audio!

In the time since the last message I sent, I actually did have Ardour [to probably invent a term] “soft crash” on me. Meaning that its UI elements went all but completely non-responsive. If I told it to play, it’d play, and if I changed, say, an automation point, that change would reflect in the playback, even if it didn’t visibly represent on the display for a good minute or two. So, at that point, I went ahead and saved and quit Ardour.

After restarting Ardour, I took your advice to kick the buffer up to 4096. And since then, I have let playback continue for a good 20 minutes or so uninterrupted, and thus far, no drops. Also, the highest figure I’ve seen thus far on the DSP gauge was a very brief 10%. Nominally, even during playback, it’s mostly stayed in the 3-6% range, and mostly in the 3-4% range. Therefore, I think the buffer DID resolve the issue (fingers crossed that it stays that way).

As for what mics I use, I use the Audio Technica AT2020, which is a wide-diaphragm, side-address, condenser XLR mic that DOES require phantom power. And actually, I have a USB audio device - an M-Audio MobilePre. It’s what I use for my audio INPUT, but I don’t use it for audio OUTPUT, simply because I get so much better sound quality using HDMI to the TV, and then optical from the TV to my Rockville BluTube Tube hybrid amplifier (running into a pair of late 70’s / early 80’s DLK 1 1/2 loudspeakers) than I do using the 3.5" stereo mini jack the MobilePre offers.

If they make either an external USB, or an internal PCIe sound card that has an optical output, then I would be more than happy to secure one of those, and then I could discontinue using HDMI for audio. And this wouldn’t even be an added burden for me since I had already planned on replacing the MobilePre with something better anyway (pretty underwhelmed with the preamps in it). I had been looking at Focusrite stuff, but I would be wide open to considering something else.

Lastly, the pop up I had referred to did in fact focus on locked memory. “Your system has a limit for maximum amount of locked memory” and so on. It gives me a chance to have it not show the message again. So I wonder if I just dismissed that alert early on with the laptop and then subsequently forget about it. Is this alert anything I need to worry about / do anything about? Or can I just click that “don’t show again” and forget all about it?

And thank you once again for all the help you’ve been! You’ve been fantastic! Once again, fingers crossed, but so far, it looks like my problem may well be resolved now with the buffer setting change.

GuntherT · September 23, 2021, 4:06am

This may be obvious, but I would also be sure your are using NVIDIA’s proprietary driver, and in the associated NVIDIA settings, check the box for “Performance”. Perhaps this is no longer a thing, but on an older computer I had with a dedicated NVIDIA card, the default video driver on my Debian-based system at the time was terrible for audio applications…constant xruns. Once I switched to the proprietary driver and clicked on the performance setting, everything worked as it should. Perhaps you have already done this, but I figured there is no harm in mentioning it.

system · December 23, 2021, 10:07am

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.