Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> writes: hdspmixer works with the Hammerfall DSP but it writes all over the mixer right on startup. Not suitable for changing single settings: I am using alsactl for that right now. Sigh, you are right. But the question remains: What applications will support this and what does it mean? For example, the DSP Hammerfall has about two dozen inputs and about two dozen outputs. What does "hardware monitoring of capture ports" mean then? Where are they monitored to by which application? -- David Kastrup

"Chris Caudle" &lt;chris(a)chriscaudle.org&gt; writes: [Large treatise regarding hardware monitoring elided] Uh, the question was not what hardware monitoring is. The question was what the --hwmon option to Jackd does and which applications support it. "the hardware is responsible for mixing the incoming audio material" is nothing that Jackd would be involved with since Jackd isn't hardware. So what does this option do? The manual page reads (as you cited): -H, --hwmon Enable hardware monitoring of capture ports. This is a method for obtaining "zero latency" monitoring of audio input. It requires support in hardware and from the underlying ALSA device driver. When enabled, requests to monitor capture ports will be satisfied by creating a direct signal path between audio interface input and output connectors, with no processing by the host computer at all. This offers the lowest possible latency for the monitored signal. Presently (March 2003), only the RME Hammerfall series and cards based on the ICE1712 chipset (M-Audio Delta series, Terratec, and others) support --hwmon. In the future, some consumer cards may also be supported by modifying their mixer settings. Without --hwmon, port monitoring requires JACK to read audio into system memory, then copy it back out to the hardware again, imposing the basic JACK system latency determined by the --period and --nperiods parameters. But what does this mean when I have 26 capture ports and 18 output ports? What kind of applications request to "monitor capture ports", and what ports will get a direct signal path between them? When I use Ardour, I have settings for "Ardour is responsible for monitoring" and "Hardware is responsible for monitoring". For which of the two settings would the --hwmon option to Jackd be even relevant? Wait. Now I see _three_ settings. Record monitoring handled by: "via Audio Driver" "ardour" "audio hardware" [Testing out several things] Ok, the "via Audio Driver" option is not there when Jackd runs on my default laptop hardware (AC97) but it is there when it runs on the RME Hammerfall DSP. But independently of whether or not I specify --hwmon. So does this option actually make a difference to Jackd? Either way, what is the effect? Does Ardour take the gain totals (disregarding all other plugin effects) from its jackd-controlled hardware inputs to its record-enabled tracks and from its record-enabled tracks to its jackd-controlled hardware outputs, convert them to mixer settings and hand them over? That would be what I consider "best case". It is also something about which I can find nothing whatsoever in the Jack API documentation (as seen on its web site). So it's hard to guess at the actual capabilities being exercised here. If it accesses the mixer like that, it's actually a bit more than just monitoring. Who does the latency accounting in this case? The Hammerfall docs state 4 samples delay at 48kHz and its ilk and 8 samples delay at 96kHz and its ilk for the digital signal paths. For the analog signals, A/D has 31 samples delay due to oversampling/filtering and D/A has 30 samples delay. So basically Ardour's menu "Editor/Audio/Monitoring/Record monitoring handled by:" gains an additional option "via Audio Driver" on certain hardware, independently of whether jackd has been started with --hwmon or not. This magic third option is not mentioned in the Ardour manual <http://manual.ardour.org/preferences-and-session-properties/preferences-dialog/audio/>: Record monitoring handled by: determines whether Ardour provides monitoring of incoming audio or whether monitoring is provided by hardware. See Monitoring(http://manual.ardour.org/recording/monitoring/) for more information. And "Monitoring" is actually less rather than more information: When recording, it is important that performers hear themselves, and to hear any pre-recorded tracks they are performing with. Audio recorders typically let you monitor (i.e. listen to) the input signal of all tracks that are armed for recording, and playing back the unarmed tracks. So does --hwmon make an actual difference (I should likely mention that I used Jack2 for this experiment)? And what actually happens? And is there any documentation about any of this and the involved APIs anywhere? And if this requires special Jackd support (as the manual page suggests) rather than being able to work with more generic ALSA-accessible mixers (like, say, the AC97 mixer), where would one find out about just which cards are supported in 2017? The manual page states "Presently (March 2003)" which is not particularly up to date. -- David Kastrup

Ralf Mardorf &lt;ralf.mardorf(a)alice-dsl.net&gt; writes: Can we focus on the question of what happens _with_ --hwmon to jackd and/or the "via Audio Driver" monitoring option in Ardour? I know what the mixer hardware can do in general and specifically when using hdspmixer (or the equivalent amixer -d hw:DSP cset numid=5 ...). But that's not relevant to Jack and wasn't my question. Sigh. I even listed the latencies involved here already. Since the mixing is in the digital domain, you get buffering delays and the delays for the down-/up-sampling filters of A/D-D/A conversion, roughly 2ms all in all. That does not even make sense. The audio interface needs to get passed information by some software in order to do something specific. It does not have a button labelled "--hwmon" on its box. I was not talking about using hdspmixer. The question was what effects jackd --hwmon and/or the Ardour monitoring option "via Audio Driver" (discovered after the initial question was already posed but very likely related) have. Also the question was where information about supported cards and the used API to Jack were to be found since the manual page describing the options represented the status as of 2003 AD. And if I am using a tape drive, I don't even need a computer. But let's assume, for the sake of solving this question, that I am using a computer, not a mixing console, an RME Hammerfall DSP (or some other supported card, whatever it may be) and am not using hdspmixer in order to set up a monitoring solution independent of Jack and/or Ardour. -- David Kastrup

I found this reply from Paul Davis (original jackd author/designer) for essentially the same question from many years back: --------------------------- On Fri, Aug 27, 2010 at 3:29 PM, Niels Mayer <[hidden email]> wrote: Most people do not use this. It is entirely replaced by using a h/w specific utility (such as hdspmixer or envy2ctl) to control signal routing. The one benefit that it has is that it means that JACK *applications* can control that kind of routing, which early in the life of Ardour seemed kind of important. It no longer seems very important. If you're already using a h/w specific utility for this purpose, then don't use -H. it doesn't really do anything. It was a placeholder for functionality that has never been implemented because (a) so few cards implement it and (b) the meter is basically useless for any app other than a h/w specific utility app (which has other mechanisms available to get the meter values). --------------------------- So it looks like this feature never really became common, and it appears that the jackd hardware monitor option only works on ICE or hdsp based cards. Maybe a few others, but unfortunately you would have to inspect the ALSA driver source to make sure. On Thu, May 4, 2017 4:17 am, David Kastrup wrote: Which mixer? The mixer in the audio interface? I don't fully understand the hardware configuration you are describing. In practical terms it seems you will be tied to a particular soundcard, or at least family of cards, since it seems only the ICE/envy24 drivers and the RME drivers implemented this feature. Maybe a few others, but good luck figuring out which. Only if the ALSA driver reports has_hw_monitoring as true. Which driver does the Roland sound control use? jackd queries the ALSA driver, and if the drivers reports has_hw_monitoring then it sets the hw_monitoring property of the driver to on if requested. If the driver reports has_hw_monitoring as false then it does nothing. That is unfortunately true. For most uses for which jack was designed, it does what it is needed and has fallen into a barely maintained "just keep it compiling" kind of state. There is a new jackd maintainer, but I think just working on it part time, and basic things like keeping man pages and web pages up to date is not being done currently. Yes, but most of them have utilities for configuring the hardware mixer. The hwmon option to jackd is just on/off, it doesn't give any way to control the gain of the connection, or the routing if there are multiple inputs and multiple outputs. I think the jackd option never caught on because it was too limited to be useful. -- Chris Caudle

On Fri, 05 May 2017 01:52:35 +0200, David Kastrup wrote: Yes, jack already could do the I/O connections, but jack can't do the hardware routing, so not only a gain control is missing for what you want to get. The abilities of audio interfaces are very different. You seem to have an idea of what does fit good to your personal needs, but what you want to get seemingly is very unusual. The routing of hardware monitoring could be much too complex, that's why hdspmixer and/or mixing consoles are usually used. Regards, Ralf

On Fri, 05 May 2017 09:42:01 +0200, David Kastrup wrote: Hi, you could mix a song using a control surface and/or automation of software such as Ardour. There unlikely is a reason to use a control surface and/or automation for hardware monitoring, hdspmixer allows to save and load as much presets as you want, 8 presets are available even without loading. A lot of Linux hardware issues are caused by the missing support of the hardware vendors. However, what you want to get is already an issue, due to the differences of audio interfaces, even if the vendor should support Linux. You expect the recording software to use the audio interface's mixer "like this", but if "like this" shouldn't be supported to "fallback to that". An AIO solution, bundled software + hardware could provide what you want to get, in a professional way. I doubt this would work very good, if software needs to care about what ever audio interface should be connected. A compromise might be to control the DAW mixer and independently to control the hardware mixer, too, IOW something like hdspmixer controlable by MIDI events. Do a lot of people need it? If so, is somebody willing to add MIDI to e.g. hdspmixer? EQs, Reverb and delay would be nice for the hardware monitoring, too and indeed, proprietary software for a lot of audio interfaces provide this. If it's provided by the vendor of your audio interface for Windows and/or Apple platforms, you should ask the vendor to support Linux, too ;). 2 Cents, Ralf

On Fri, 05 May 2017 19:14:52 +0200, David Kastrup wrote: That's absurd, since the different sound cards provide completely different routing features. If you mix a project with a DAW, then the software mixer should be completely separated from the hardware mixer. If you want to get all in one, consider to just use the I/Os of an audio interface and to buy the right tool for that task, a separated mixing console [1]. Yes, hardware monitoring done with an external mixing console [1] very often is done by adding effects to the monitor signal, so some proprietary audio interface software provides this for the audio interface's hardware monitoring, too. The audio interface's hardware monitoring is done at driver level, while the software could be split to the driver and mixer software, the access to the hardware monitoring still is part of the driver. Jack plugins? Driver level? Jack is a sound server using a backend such as ALSA. Keep in mind that it's common practise to use real mixing consoles [1] and/or to use the audio interface's hardware mixer in addition to the DAW's mixer. Most people do not have the same needs as you have got [2]. I'm using hdspmixer for my RME audio interface. My Focusrite isn't supported, so I'm using it class compliant, without the option to have access to the hardware monitoring. Actually a driver for other Focusrite interfaces from the same series exists and I much likely only need to add an ID to the driver's source code and build it, to get access to the hardware monitoring, but I simply don't need it. A lot of people don't need hardware monitoring provided by the audio interface. Those who need it, usually like to use the separated audio interface's hardware mixer. I never heard from anybody who shares the same need as yours. There are for sure people who share your wish, but you will not find that many who do so, that seemingly is the reason that nobody wrote the code you wish to have. Regards, Ralf [1] not necessarily an analog mixing console, it just means that it is a mixing console and not just a remote control. However, even a separated mixing console, analog as well as digital, could send and receive data from a DAW or use it's own automation sequencer synced to the DAW. OTOH a cheap mixing console already could be used to separate the real mix, probably just done by a software mixer and the monitor mix, done by the cheap mixing console. So you could put the remote control for the DAW's mixer and the mixing console to each other. If you want to do the complete mix with a mixing console, you have to get one in a different price segment, to get professional sound quality, but then you really get all in one. [2] On Thu, 4 May 2017 17:35:24 -0500, Chris Caudle wrote:

On Sat, 06 May 2017 10:41:53 +0200, David Kastrup wrote: A harp takes less space than a drum kit. Use the luggage check-in instead of handluggage or simply use a van. IOW you need to do what's appropriate for you business. It also might be possible to not to take the drum kit or mixing console with you, but to borrow one at the location where you need it. If you fly from Germany to the USA, you usually don't take your car with you, you usually would borrow one from rent-a-car. On Sat, 06 May 2017 10:41:53 +0200, David Kastrup wrote: You ignore the arguments. 1. Different audio interfaces provide completely different routing capabilities, so what you want to get isn't that easy to do, if at all. 2. Not a lot of people have the same needs as you have got. Most people want to have the audio interface's hardware mixer separated from the DAW's software mixer, let alone those who simply use the I/Os of the audio interface and a mixing console. Note! If you mix the DAW's software mixer with the audio interfaces mixer, you get a hybrid, you could add effects to the mix, but not to the monitor mix. The only way to get a real all in one solution is just using the audio interfaces I/Os and to do the complete mix using a mixing console. Regards, Ralf

On Sat, May 06, 2017 at 11:27:31AM +0200, Ralf Mardorf wrote: For anything non-trivial, just count the number of mic stands and kilometers of cable you'll need and then work out if that fits in your cabin luggage :-) Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)

Ralf Mardorf &lt;ralf.mardorf(a)alice-dsl.net&gt; writes: Uh, I described the exact application I was currently working on where I found the existing connectivity lacking. To make it easy for you, let's append the scripts in their current state: Here is olifant.sh: --- cut --- #!/bin/sh # Hammerfall DSP # Routing is input,output,gain (with 32768 being 0dB) # # Inputs to HDSP Mixer # ===================================================================== # Multiface analogue inputs 1-8 = amixer source channels 0-7 # [8-15 unused for Hammerfall DSP] # Multiface ADAT inputs 1-8 = amixer source channels 16-23 # Multiface SPDIF input = amixer source channels 24-25 # alsa_pcm:playback_1-26 = amixer source channels 26-51 # Outputs from HDSP Mixer # ===================================================================== # Multiface analogue outputs 1-8 = amixer destination channels 0-7 # [8-15 unused for Hammerfall DSP] # Multiface ADAT outputs 1-8 = amixer destination channels 16-23 # Multiface SPDIF output = amixer destination channels 24-25 # Multiface line (headphone) output = amixer destination channels 26-27 # Mapping between Multiface inputs and alsa_pcm:capture channels # ===================================================================== # Multiface analogue inputs 1-8 = capture_1-8 # Multiface ADAT inputs 1-8 = capture_9-16 # Multiface SPDIF input = capture_17-18 amixer -q -D hw:DSP -s <<EOF sset 'Sample Clock Source' 'Internal 96.0 kHz' cset numid=5 26,0,10000 cset numid=5 27,1,10000 cset numid=5 26,26,10000 cset numid=5 27,27,10000 EOF OLIFANT_AMIXER_DEVICE="hw:DSP" OLIFANT_AMIXER_UNMUTE="cset numid=5 0,0,32768 cset numid=5 1,1,32768 cset numid=5 0,26,32768 cset numid=5 1,27,32879" OLIFANT_AMIXER_MUTE="cset numid=5 0,0,0 cset numid=5 1,1,0 cset numid=5 0,26,0 cset numid=5 1,27,0" export OLIFANT_AMIXER_DEVICE OLIFANT_AMIXER_UNMUTE OLIFANT_AMIXER_MUTE jackd --silent -d alsa -X seq -d hw:DSP -s -H -r 96000 -p 2048 -n 2 & sleep 1 aeolus -I Aeolus2 -S $HOME/.aeolus/stops & sleep 1 jack_connect aeolus:out.L system:playback_1 jack_connect aeolus:out.R system:playback_2 # Oh come on, this is too stupid for words: there must be a better way # to look up a port alias. And besides, mididings should really also # accept an alias. INPUT=$(jack_lsp -A|awk '/^[^ ]/{canon=$0};/Hammerfall-DSP:midi\/playback_1/{print canon;exit};{next}') mididings -I "$INPUT" -O aeolus:Midi/in -f $HOME/share/mididings/olifant.py --- cut --- And here is $HOME/share/mididings/olifant.py: from mididings import * from mididings.extra import * from mididings.extra.inotify import AutoRestart # command line processing? import os if 'OLIFANT_AMIXER_DEVICE' in os.environ: import subprocess amixer_pipe = subprocess.Popen(['amixer','-q','-D', os.environ['OLIFANT_AMIXER_DEVICE'], '-s'],stdin=subprocess.PIPE) amixer_unmute = os.environ.get ('OLIFANT_AMIXER_UNMUTE') amixer_mute = os.environ.get ('OLIFANT_AMIXER_MUTE') def roland_unmute (ev): if amixer_unmute: amixer_pipe.stdin.write (amixer_unmute + '\n') def roland_mute (ev): if amixer_mute: amixer_pipe.stdin.write (amixer_mute + '\n') else: def roland_unmute (ev): return def roland_mute (ev): return config( backend='jack-rt', client_name='olifant', # Gives Roland a big organ initial_scene=1, ) hook( AutoRestart () ) rolandAI = 1 # accordion treble rolandAII = 2 # accordion chord (non-Roland setting) rolandAP = 3 # accordion bass/free bass (non-Roland) rolandADrum = 10 # drums rolandI = 4 # orchestra/organ treble rolandP = 5 # orchestra/organ bass buttons rolandII = 6 # orchestra/organ chord buttons rolandIII = 7 # free bass manual rolandSets = 13 # set selection aeolusP = 1 # Pedal aeolusI = 2 # Great aeolusII = 3 # Choir aeolusIII = 4 # Schwell aeolusCtl = 2 # Global control channel # It's a bit complex to decide just when to switch the Roland sound # off via mixer (which will disable both treble and bass) and when # not. # # Various policies may be implemented, but here we use a comparatively # simple default: # # For playing organ parts in the right hand, we want to have ready # access to register switches of the right hand (which would reenable # a temporarily muted Roland voice). So in the organ registers of the # right hand, we mute the Roland. # # There is one major nuisance: switching from organ mode to accordion # mode may well not send any Midi event at all. As a result, we will # detect a scene change only once a note is played (or a register is # pressed). scene_sets = { 1: Scene ("Roland mode", ChannelFilter(rolandI) >> ProgramSplit({5:[SceneSwitch(2), Program (1, aeolusCtl, 1)], 6:[SceneSwitch(2), Program (1, aeolusCtl, 3)], 7:[SceneSwitch(2), Program (1, aeolusCtl, 5)], 8:[SceneSwitch(2), Program (1, aeolusCtl, 7)], 9:[SceneSwitch(2), Program (1, aeolusCtl, 2)], 10:[SceneSwitch(2), Program (1, aeolusCtl, 4)], 11:[SceneSwitch(2), Program (1, aeolusCtl, 6)], 12:[SceneSwitch(2), Program (1, aeolusCtl, 8)]}), [Call(roland_unmute)]), 2: Scene ("Organ mode", Split({NOTE: ChannelSplit({rolandAI: SceneSwitch (1), rolandI: Channel (aeolusI), (rolandAII,rolandII): Channel (aeolusII), rolandIII: Transpose (-12) >> Channel (aeolusIII), (rolandAP,rolandP): Transpose (12) >> Channel (aeolusP)}), PROGRAM: ChannelSplit({rolandAI: SceneSwitch (1), rolandI: ProgramSplit({ (1,2,3,4): SceneSwitch(1), 5: Program (1, aeolusCtl, 1), 6: Program (1, aeolusCtl, 3), 7: Program (1, aeolusCtl, 5), 8: Program (1, aeolusCtl, 7), 9: Program (1, aeolusCtl, 2), 10: Program (1, aeolusCtl, 4), 11: Program (1, aeolusCtl, 6), 12: Program (1, aeolusCtl, 8)}), rolandSets: Ctrl(1, aeolusCtl, 32, EVENT_PROGRAM)})}), [Call(roland_mute)]) } run (scenes = scene_sets) --- cut --- olifant.py, the mididings script, is supposed to be generally useful to people independent of what sound card they use. It needs to switch off the Roland accordion output in the mixer (that's what the roland_mute and roland_unmute calls are for), and it does not make sense to simulate a hardware mixer with the more demanding full-duplex software-mixing approach. So what I do here in order to keep things generally useful is passing an ALSA device and amixer commands to use via environment variables. That will cover the vast majority of the use cases workable via hardware mixers accessible in some manner via ALSA. But it is a total crock to use that side path for functionality that falls squarely in the realm of sound routing. When there is no viable hardware mixer, one has to use Jackd routing anyway. So what's wrong with Jackd gaining the ability to offload work to hardware whenever the hardware is able to do the job? This particular application can be fudged around, sure. But it's not like software-controllable setup of hardware monitoring is useless for recording applications like Ardour. And it does make sense to save your monitoring solutions as part of an Ardour session rather than having to manage them with separate applications not connected with the Ardour session control. -- David Kastrup

Ralf Mardorf &lt;ralf.mardorf(a)alice-dsl.net&gt; writes: Sure, and professionals don't use Ardour or GNU/Linux (or Windows 10) either but custom hardware and systems. But this is "jack-devel" so it does not matter what "professionals" do but rather what users of Jack do. I'd use the term "disspell" instead of "ignore". Sorry, but that's just handwaving. An audio interface will either be able to route some input to some output with a given volume or not. The API to jack (or something doing that kind of job for the connection management on its behalf) would just request the connection and would not need to know how it was going to be established. Many many soundcards already provide amixer controls that can be used for this functionality if you know how, and the "if you know how" part can be described in a database. As the database grows, more cards will transparently support hardware monitoring. It most definitely _is_ easy to do since the hard work is in the ALSA controls of individual drivers (or even other kinds of command line utilities used for accessing mixers) and those are already there for a whole lot of cards. And because different people have different needs, flexibility is a bad idea? I don't buy it. Not without the system reverting back to software. So? If you were recording from a Firewire card to a Firewire hard disk, in old times the data did not even touch your computer (Firewire interfaces are a security nightmare because of that) if the software was smart enough to notice that it did not actually need to access the data. That kind of "let the hardware do the job on its own whenever it can" mind frame was what made Firewire the choice for professional work for a really long time. So the user notices that monitoring with effects leads to larger time lag and larger CPU load and higher likelihood of dropouts. He has a choice then. He can switch off the effects. I repeat: analog consoles are dying out. People use digital controllers. It's just frustrating that all the _actual_ work is already done but there is no way to plug the pieces together except for making up your own makeshift solution that will benefit noone else. -- David Kastrup

Ralf Mardorf &lt;ralf.mardorf(a)alice-dsl.net&gt; writes: If access to hardware mixers were as useful as a flying car, one has to wonder why the ALSA programmers bothered providing it for a lot of cards. At any rate, your point of "nobody should want that or talk about it" is abundantly clear without all the flowery comparisons you make. Putting together something for producing sound using Midi controllers for controlling more than a single part of the sound setup is not exactly outlandish. That's what digital controllers are for in the first place. You are the one who claims that Jackd should not be allowed to control hardware monitoring because professionals use other hardware. That's a single application I put together where it struck me as strange that there seemed no ready application to do a rather mundane thing. Not really. I'll have to read the source code of Jack, the source code of ALSA drivers, and the source code of Ardour (assuming that the "use Audio Driver" option is either related to what I hoped what --hwmon would do or to what it actually does) to figure stuff out because nothing is actually documented or readily available knowledge. What _is_ obvious is that nobody appears to be actively working on any of what I was suspecting --hwmon to be useful for. Because nobody bothered implementing stuff. That's not the same as that there would be no point to implementing it. -- David Kastrup

Ralf Mardorf &lt;ralf.mardorf(a)alice-dsl.net&gt; writes: RME? The company that provided all the information needed for writing stable ALSA interfaces for the RME Hammerfall, writing hdspconf, and writing hdspmixer? I think they've done everything expected from a nice player. The usefulness of what they have done definitely beats the crap from companies "supporting" Linux like Nvidia, with no information but proprietary drivers that stop working after a number of years. RME hasn't written hdspconf. They only made it possible. What makes you think I want to "replace audio interfaces". I wouldn't know. I don't use Microsoft or Apple based platforms. Anybody here who does? -- David Kastrup

Ralf Mardorf &lt;ralf.mardorf(a)alice-dsl.net&gt; writes: So what do you call "support" that is available for other operating systems? Interesting: I would have thought that hdspmixer is mostly confined to HDSP cards. Strange. The HDSP has 8 channels in Jack. Assuming that with channel you mean one audio signal rather than one ADAT connector. So I'd have expected either 8 or 0 supported channels. 2 is a strange number. I can't find an "RME AIO" on their web page (either under current or legacy cards) so I cannot even guess. Some of the latency is due to digital oversampling filters in A/D&D/A. Reducing that latency (about 2ms) is not going to improve sound quality. I am more concerned with unnecessary full-duplex operation at 96kHz: it increases the likelihood of xruns. Also it feels like additional latency in the analog path for a mere relay of a signal is a bad idea. Admittedly that argument seems a bit weak when my other way of sound production runs through serial Midi first. But the cost for that at 3 bytes per note is just 1ms (more for chords). Well, my specs are 2.5GHz Penryn and 4GB of memory (extending memory to 8GB with DDR2 SODIMM would be about as expensive as the whole computer was, and for audio recording it would not appear to make a difference). Bottlenecks are more likely bus speed (800MHz I think, but with the RAM connected with 667MHz) than anything else. And current kernels. -- David Kastrup

Ralf Mardorf &lt;ralf.mardorf(a)alice-dsl.net&gt; writes: For old cards, that amounts to providing a download for old stuff. I doubt that the support will amount to more than that. That does not sound like a description of "support". Ubuntu lowlatency with threadirqs enabled. I am more in the 1024 or 2048 ballpark with 96kHz and the Hammerfall DSP. Which is a bit irritating since the Mackie Onyx Firewire card is better satisfied with 512 samples running over the builtin Ricoh Firewire controller of the Thinkpad T61. That combination does not sound like it should work better than the Hammerfall Cardbus interface. I was not actually pitching for "pleasing me" but rather for figuring out whether Jack/GNU/Linux get the best possible use of available hardware. Since the usual consequence of an xrun is to make whatever application is currently running crash and burn (probably the process of bringing an xrun to attention is tying up enough time to cause the next xrun), I am not as much interested in latency optimization as I am in xrun elimination at the moment. And the change between full and half duplex makes a noticeable difference in my perception. -- David Kastrup

Ralf Mardorf &lt;ralf.mardorf(a)alice-dsl.net&gt; writes: Downsampling from 48kHz to 44.1kHz is a lot uglier than from 96kHz. Equalizers are a lot more similar to their analog counterparts when you stay in good distance from the Nyquist frequency (you get frequency warps otherwise). Downsampling to consumer frequencies can use a lot better filtering without realtime constraints. Nonlinear processing (like tube amp simulations and other distortions or pitch changes) may bring inaudible frequencies into the audible domain. And the analog circuitry for cutting out aliasing is a lot more relaxed when working between 32kHz and 96kHz rather than 20.7kHz and 22.05kHz (numbers pulled from the frequency ranges of the Hammerfall's specs). When using a handheld recorder with electret capsules, I use 16bit/48kHz. I can set it to 24bit/96kHz, but the additional storage is just spent on noise and fantasy. Well, I thought that Ubuntu Studio (though I don't know whether the actual distribution from scratch differs from apt-get install ubuntu-studio) should more or less know what it's doing. But I haven't investigated. But there _are_ also some instructions on the net regarding how to set up control groups best for audio, and I haven't looked at that either yet. -- David Kastrup

You mentioned Ubuntu Studio. The good news, by default Ubuntu Studio does use rtirq to optimize audio, the bad news, for some Ubuntu Studio release's updates rtirq didn't fit to the provided kernel, so it didn't work at all. Even if the rtirq script should work, you sometimes still could optimise it's config.

On Sat, 06 May 2017 22:24:29 +0200, David Kastrup wrote: Much likely it's Rui's rtirq script. For what ever reason Ubuntu keeps it in init.d and doesn't start it by a systemd unit. http://packages.ubuntu.com/yakkety/rtirq-init Instead of ps, you could run /etc/init.d/rtirq status I can't speak for your computer, but usually rtc shouldn't be prioritised anymore and irqbalance should be completely removed. First stay with rtc prioritised, but uninstall irqbalance. https://wiki.archlinux.org/index.php/Professional_audio#Tips_and_Tricks Take a look at /etc/default/rtirq (on Arch Linux it's /etc/conf.d/rtirq ;): [rocketmouse@archlinux ~]$ grep RTIRQ_NAME_LIST /etc/conf.d/rtirq | grep -v "#" RTIRQ_NAME_LIST="usb snd_hdsp snd_ice1" The name list doesn't contain rtc and i8042 anymore. My mouse is an USB mouse, but the keyboard still is PS/2. Check the output of cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor Perhaps setting it to performance helps to reduce xruns echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor Regards, Ralf

David Kastrup &lt;dak(a)gnu.org&gt; writes: Well, there is irq/16-snd_hdsp after all once I plug the Cardbus card in (it's usually out in the morning since the computer doesn't wake up successfully from suspend otherwise). And it's prioritized well enough once I _rerun_ /etc/init.d/rtirq. Otherwise it sticks at the bottom. Ok, something to keep in mind. -- David Kastrup

On Sat, 06 May 2017 19:15:02 +0200, David Kastrup wrote: No, when using external gear running status reduces it to 2 bytes, as long as just one MIDI channel is involved. Simply use one MIDI interface, for each MIDI channel ;). 1 ms as a fixed delay isn't an issue at all. I'm very sensitive to MIDI jitter, much more than it is expected from a "normal" human being :D. You should use alsa-midi-latency-test to check how much MIDI jitter you get. Very likely you get more than 1 ms of MIDI jitter. Regards, Ralf

On Sat, 06 May 2017 20:58:30 +0200, David Kastrup wrote: I guess we get closer to your "real" issue ;). Consider to open a thread at https://lists.linuxaudio.org/listinfo/linux-audio-user not regarding hardware monitoring, but regarding improvement of latency (for your needs) and/or issues that might be completely unrelated to latency. Keep in mind Aeolus is emulating a real pipe organ, so you could value some latency as a feature ;). I'm with you, regarding issues. I only disagree regarding hardware monitoring. I don't know if the girls and boys at linux-audio-user could help you, but in my experiences it's the best place to get closer to the target. The most worse situation could be no help at all, but at least get some black humour including real empathy. ====================== ;) Ralf

On Sat, 06 May 2017 20:58:30 +0200, David Kastrup wrote: Did you notice that the coder of Aeolus already replied to this thread? :) He is subscribed to Linux audio users, too. I suspect he could help you regarding issues that are related to Aeolus, assuming it should be issues caused by Aeolus. If not, it anyway would help troubleshooting.

Tobias Hoffmann &lt;lfile-list(a)thax.hardliners.org&gt; writes: It wasn't getting anywhere, though. I wasn't thinking as much about "detecting" but rather "having readily available knowledge about the ability to ...". "Readily available knowledge" implies a database, and matching that database to Jackd's topology needs does not sound like something to be done in a realtime process. But the per-card data might be converted into directly usable form by some sort of daemon and handed over to Jackd. I'll try hunting it down eventually. Would provide some closure for this thread. That's its current hardware interface. But let's not forget that Jack also dabbles in software inputs and outputs (like aeolus:midi/in and similar). You are quite correct that I did not think through that hardware-input and capture-input do not have an implied 1:1 relation. Since Jack can also handle software-provided end points, it would seem that the basic underlying flexibility should be there for _normal_ configurations (providing and particularly listing one Jack port for every potential sound source available on a telephone network to a hardware interface of my phone would certainly not work all too well as an API). Well, an API for accessing something like the matrix mixer of a Hammerfall DSP Multiface only with on/off settings would be a bad idea (actually, even its headphone output volume can only be adjusted via the internal mixer: I don't consider that a good design choice and it has been changed in the Multiface II, but any on/off only routing design would likely clash with utilities and commands intended to do more fine-grained control). Agreed. So the question is: can we envision a unified API and access method to access one or several utilities of that kind outside of the current scope of Jack? I think that being able to control mixers and routing via Ardour mixer strips (thus also making them available for automation within an Ardour session and for access via Midi controllers) would make a lot of sense. I am not in disagreement here. The one redeeming feature of ALSA mixer control is that it exists. Which is a whole lot better for playing around than not existing. [Several abominations deleted] I wasn't going to propose that mapping everything through ALSA was the best course. Badly done or not, the availability of ALSA for a long time has had an influence of the features available to some degree or other to soundcard users. Sometimes a bad solution is needed for the motivation and insight for developing a better solution. But they do it in their own realtime OS rather than handing it off to a general-purpose desktop computer to let it fight out the realtime constraints with its applications. "Hardware" does not mean "not using computers" these days, more like "not using computers under user control and responsibility". Right. So the question is just how to arrive at a point where most of the slow-changing controls of a soundcard (mixers and multiplexers being prime examples) can be accessed from an application like Ardour in a consistent and automatable manner. Jack might not be the solution, perhaps. But what could be? -- David Kastrup

Ralf Mardorf &lt;ralf.mardorf(a)alice-dsl.net&gt; writes: It's not like the "via Audio Driver" option for monitoring in Ardour is documented in its manual in any way, so sane people seem to prefer not having any information in the manuals that might be useful but detracting from sane work-flows. I wouldn't know. I find sane people hard to understand. -- David Kastrup