I'm running Debian in a virtual machine, with a passthrough to a USB port, playing to an audio gadget as the output device. To avoid clipping (regardless of what application is playing sound), I've set Debian's 'maximum-volume' slider to 50%. The output-volume slider then correctly says 50% as its maximum setting. It mostly works well... but sadly isn't proving trustworthy. Glitches cause Debian to forget about the 50% limit (even though the output slider still claims that is max) and I get full volume output. I have my amps set to assume 50% at max, so that is quite loud!
Unfortunately I'm not very experienced with Linux yet, end even less so with its audio chain. Is there a method of setting the maximum output level such that Debian won't overlook it? Perhaps on a similar note, it would also be handy if there was a way to stop Debian swapping to other output cards, when the default audio gadget is temporarily absent?
Thanks,
Kev
Unfortunately I'm not very experienced with Linux yet, end even less so with its audio chain. Is there a method of setting the maximum output level such that Debian won't overlook it? Perhaps on a similar note, it would also be handy if there was a way to stop Debian swapping to other output cards, when the default audio gadget is temporarily absent?
Thanks,
Kev
Thank you, Charlie. Yes, the audio gadget is a raspberry Pi, so that could work; I'll look into it. I'd imagined the clipping may originate at any point, so reducing levels at the source seemed logical. But actually yes, it is CamillaDSP that reports clipping, which is immediately after the audio gadget.
Debian is using PulseAudio. Though I also see mention that the Server Name is: PulseAudio (on PipeWire 0.3.65). I vaguely understood (in concept) PulseAudio running on top of ALSA, and have also had occasional (uneasy) dealings with JACK and GStreamer. Quite confusing combinations already, but now there is also PipeWire that seems potentially interesting, but is even more vague in my understanding.
Hmm. If I'm going to use Linux for (serious) audio, I shall need to learn more about all this. Which might be a bit painful, but would be very useful.
Thanks (yet) again,
Kev
Debian is using PulseAudio. Though I also see mention that the Server Name is: PulseAudio (on PipeWire 0.3.65). I vaguely understood (in concept) PulseAudio running on top of ALSA, and have also had occasional (uneasy) dealings with JACK and GStreamer. Quite confusing combinations already, but now there is also PipeWire that seems potentially interesting, but is even more vague in my understanding.
Hmm. If I'm going to use Linux for (serious) audio, I shall need to learn more about all this. Which might be a bit painful, but would be very useful.
Thanks (yet) again,
Kev
Plus Pipewire, apparently the default in Debian Gnome: https://en.wikipedia.org/wiki/PipeWire
Light up another VM? Sounds like you already have the experience to comfortably manage Linux on bare metal.
@Kev06 : Well, if you want to be sure your amp never receives high peaks from the soundcard, you should add fixed attenuators to the soundcard output. Because in case of a buffer issue (which you can never 100% prevent in a PC system) the bytes of the digitally-attenuated signal can be temporarily shifted, downstream from the attenuation, making a digital signal close to max possible..
If your downstream chain is OK with possible (though highly unlikely) short-time max signal from your soundcard, you can e.g. hard-code attenuation into alsa config (e.g. using the route plugin) and tell your audio server to use that fix-attenuated PCM device only, instead of the card device directly (config principle e.g. https://wiki.archlinux.org/title/PipeWire#Use_ALSA_dmix_devices_as_PipeWire_sinks ).
Pipewire is just a new replacement for Pulseaudio, the same principles apply (though a different configuration)
If your downstream chain is OK with possible (though highly unlikely) short-time max signal from your soundcard, you can e.g. hard-code attenuation into alsa config (e.g. using the route plugin) and tell your audio server to use that fix-attenuated PCM device only, instead of the card device directly (config principle e.g. https://wiki.archlinux.org/title/PipeWire#Use_ALSA_dmix_devices_as_PipeWire_sinks ).
Pipewire is just a new replacement for Pulseaudio, the same principles apply (though a different configuration)
rdf: That is very interesting, thanks. I'm using Cinnamon on Debian at the moment but just because it is my favourite desktop, I could get along with Gnome instead for what I do with audio and media.
Yes I've run Linux on bare metal several times, and in fact I've gone with it for my only OS this time - prematurely given my limited experience with it but I will get there eventually.
However, I still like to separate my tinkering and fun stuff from endangering my more important/work stuff. In the past that meant separate machines, but that seemed inefficient so I invested in making a fanless modern desktop PC that can easily run separate VMs. The concept is good and I 'love' the easy backup of VMs, I even got USB-passthrough working well for a DAC. But there have been some unpleasant surprises, like audio loop-backs apparently having issues without direct hardware access and even things like opening a different VM affecting audio output on a running one.
Using the raspberry Pi as an audio gadget is an attempt to get a dedicated hardware device to help with some of this. IMO it also makes sense to have ithe Pi handle the particular configuration needed by a set of active bi/tri amped speakers. A different set of speakers would have a different Pi. Leaving the VM to handle all the local and internet sources and just send a generic stereo output to the Pi.
Yes I've run Linux on bare metal several times, and in fact I've gone with it for my only OS this time - prematurely given my limited experience with it but I will get there eventually.
However, I still like to separate my tinkering and fun stuff from endangering my more important/work stuff. In the past that meant separate machines, but that seemed inefficient so I invested in making a fanless modern desktop PC that can easily run separate VMs. The concept is good and I 'love' the easy backup of VMs, I even got USB-passthrough working well for a DAC. But there have been some unpleasant surprises, like audio loop-backs apparently having issues without direct hardware access and even things like opening a different VM affecting audio output on a running one.
Using the raspberry Pi as an audio gadget is an attempt to get a dedicated hardware device to help with some of this. IMO it also makes sense to have ithe Pi handle the particular configuration needed by a set of active bi/tri amped speakers. A different set of speakers would have a different Pi. Leaving the VM to handle all the local and internet sources and just send a generic stereo output to the Pi.
phofman: thanks for those ideas; more to look into.
The DAC/soundcard can attenuate and the amps have volume knobs too, so I can limit what the drivers can recieve. So it is less a problem of damage and more a problem of unexpectedly annoying the residents of adjoining apartments; I work unsociable hours, so am often listening whilst they are asleep..
But in terms of quality, the clipping is happening before the DAC/soundcard so I prefer your alsa suggestions, even if they might occasionally be circumvented. Alsa seems reassuringly low level (compared to a GUI trying to manage pulseaudio).
The DAC/soundcard can attenuate and the amps have volume knobs too, so I can limit what the drivers can recieve. So it is less a problem of damage and more a problem of unexpectedly annoying the residents of adjoining apartments; I work unsociable hours, so am often listening whilst they are asleep..
But in terms of quality, the clipping is happening before the DAC/soundcard so I prefer your alsa suggestions, even if they might occasionally be circumvented. Alsa seems reassuringly low level (compared to a GUI trying to manage pulseaudio).
A bit of searching has suggested that this might indicate I'm actually running PipeWire but with a PulseAudio compatibility layer on top. So another layer of complexity, that I wasn't even aware of. I clearly have a lot to learn if I'm to understand enough to take control of my audio chain.
I'm not yet sure if this is a VM problem or a Debian-Cinnamon one, but you could well be correct that direct hardware installation cold solve it. VMs are turning out to have more issues than I'd anticipated. I think conceptually they are the the future for me, instead of separate physical machines, but perhaps their shortcomings combined with my currently limited Linux skills mean it is too early for me to go this way. Though in this case there are lots of suggestions above for me to try, which is encouraging.
Unfortunately dual booting isn't appropriate here as I need to run my audio/media machine whilst I'm using my main one. But as time goes on I'm getting closer to ditching the VM and buying a small physical laptop for the purpose. Audio-loopbacks would then work properly, meaning the laptop could handle the crossover and DSP directly, so I'd be able to ditch the Pi audio gadget as well.
Unfortunately dual booting isn't appropriate here as I need to run my audio/media machine whilst I'm using my main one. But as time goes on I'm getting closer to ditching the VM and buying a small physical laptop for the purpose. Audio-loopbacks would then work properly, meaning the laptop could handle the crossover and DSP directly, so I'd be able to ditch the Pi audio gadget as well.
You might find Ubuntu Studio interesting. Low latency kernel already set up and various Linux sound bits and pieces pre installed.
The full Studio release uses KDE as a desktop but recollect that the facilities it offers can be installed on any Ubuntu flavour so all desktops can be used with it. (see it's web site) Personally I prefer KDE and have used it for ~25years or more. Some people derive similar features on Gnome - an option but if some one wants a menu driven desktop I feel it's better to pick one that offers it by design. The Gnome mods try to roll it back to much earlier versions.
Ubuntu also offer long term releases. This means stable applications are available for it during it's update period.
The full Studio release uses KDE as a desktop but recollect that the facilities it offers can be installed on any Ubuntu flavour so all desktops can be used with it. (see it's web site) Personally I prefer KDE and have used it for ~25years or more. Some people derive similar features on Gnome - an option but if some one wants a menu driven desktop I feel it's better to pick one that offers it by design. The Gnome mods try to roll it back to much earlier versions.
Ubuntu also offer long term releases. This means stable applications are available for it during it's update period.
Yes, ubuntu studio is interesting, and I have wondered if the various audio bits and pieces you mention might give me a head start.
Though rightly or (quite probably) wrongly, I finally concluded that the audio stuff it is loaded with is over-complicated for my simple needs. I only play audio (no live recording or production, for example) which almost any distro should do easily; low latency and all the jack stuff seem unnecessary complication, even more so the video and graphics aspects. So I thought that I might be better off with a simple and relatively lighter distro, really.
Though rightly or (quite probably) wrongly, I finally concluded that the audio stuff it is loaded with is over-complicated for my simple needs. I only play audio (no live recording or production, for example) which almost any distro should do easily; low latency and all the jack stuff seem unnecessary complication, even more so the video and graphics aspects. So I thought that I might be better off with a simple and relatively lighter distro, really.
Anyway, I've been doing some more tests and (as rdf seemed to feel) there are odd VM things going on; so it is unlikely to be the distro or desktop at fault. If I watch the info that CamillaDSP provides in the terminal, doing things with other VMs affects what is going on with my audio VM and its communication with the audio gadget; which really isn't what I wanted or expected. In some cases I just need to open another VM (and not even run/boot it) for the volume in the running audio VM to go to 100%.
That is with KVM/QEMU. There are alternatives like Virtualbox and whatever Microsoft is doing now, but they don't really appeal to me very much. So I might put serous thought into returning to a real machine for audio/music purposes instead.
That is with KVM/QEMU. There are alternatives like Virtualbox and whatever Microsoft is doing now, but they don't really appeal to me very much. So I might put serous thought into returning to a real machine for audio/music purposes instead.