On Sat, Feb 13, 2016 at 9:50 PM, jonetsu(a)teksavvy.com <jonetsu(a)teksavvy.com> wrote: 50 is the default for processes, higher is more priority. This machine runs jack with RT priority 89. Find out what your top real-time priority (aka rtprio) tasks are: $ ps -eo rtprio,comm --sort -rtprio | head -n 30 Each CPU will have one "migration" and one "watchdog" at 99, after that you should have: 1) Soundcard interupt * 2) jackd process * Depends on soundcard, check output of $ cat /proc/interrupts and find the interrupt for the Delta1010 Eg: 90 soundcard interrupt 89 jackd The important thing is the *order* of the tasks, *not* the number itself. They are serviced based on order, as fast as possible. Jack2 / dbus / pulseaudio issue by the looks. I'll leave this to google, or somebody more familiar with the issue - I have JACK1 and no manual setup of everything, so don't experience this issue ever. *Always* run jackd as the user that you will be doing the sound processing as - do not run jackd as a system daemon while logged in as a user, it causes headaches. These are called xruns, that can be solved by properly tuning you system. Your distro, or system setup. I personally advise keeping things simple, and manually start jack when you want it started, with the exact settings you want to start it with. Yes this requres some JACK knowledge, but it is reliable, and consistent. Probablty because pulseaudio takes over the soundcard when JACK releases it. Again, keeping things simple and manually starting / stopping ensures this situation never occurs. Dunno, I start jack with a minimal command, and it works every time :) Hope that helps, -Harry PS: These are known issues, and I've written up some tuning tips that I've used in the past to squeeze every drop of RT performance from a machine: http://openavproductions.com/real-time-latency-tuning/ -- http://www.openavproductions.com

On Sat, Feb 13, 2016 at 10:23 PM, jonetsu(a)teksavvy.com &lt;jonetsu(a)teksavvy.com&gt; wrote: See the "Running RtIRQ" section of the real-time tuning page, and you'll see how to set the priority IRQ for the soundcard (summarized below): http://openavproductions.com/real-time-latency-tuning/ Summary: 1) Get PID of task that services the soundcard interrupt: ps -eo pid,rtprio,comm --sort -rtprio | head -n 30 2) Change the priority of that task: chrt -f -p 84 <PID of IRQ handler> "Good" depends on use case ;) The "real" measure of latency is much more representative than the number of frames in a buffer. Samplerate, number of buffers, and buffer-size are the 3 factors for latency. There is also some latency in the ADC and DAC converters (no flame-discussions indented :) Its easy to measure the total round-trip delay: jack_iodelay For full info, read here: http://apps.linuxaudio.org/wiki/jack_latency_tests For testing, just run jack_iodelay, and then connect a loopback cable to the soundcard (aka, output -> input). Connect jack_iodelay to the soundcard's hardware input/output ports you just patched, and jack_iodelay will tell you a very precise amount of latency. Example screenshot: http://openavproductions.com/realtime_latency.png I run jackd with -p 48 -n1 -r48000, causing a theory of 1ms input, and 1ms output. Note: -n1 makes no sense, see that jackd/alsa corrects this to -n2, because one input and one output buffer is needed. So in theory, we have 2 * 48 / 48000. round trip latency: 2ms. jack_iodelay actually measures 6.629. Why? ADC / DAC conversion delay. The soundcard in use here is an "Art USB Dual Pre", retails for < 100 euro. These converters will probably not be particularly low-latency ones. For curiosities sake, would you mind measuing the round-trip delay? (Assuming you have a loopback cable available and time :) I think you might be surprised... because I always am that its actually worse than we think, because I usually look at the software "theory" latency, instead of actually measuring :D Cheers, -Harry -- http://www.openavproductions.com

To get rid of xruns during a recording you could try to record with some instruments/tracks disabled. Recording and mixing with different latency works when using Ardour, but not necessarily when using other DAWs. You could stay with one latency, if you're using monitoring that is independent of the software. Hardware monitoring could be very useful.

On Sat, 13 Feb 2016 19:15:06 -0500 &quot;jonetsu(a)teksavvy.com&quot; &lt;jonetsu(a)teksavvy.com&gt; wrote: I should mention that I record 90% of the synth tracks. I do not record MIDI notes in most cases. There is not a handful of software synths playing each time the session is being played. This is lighter on the CPU.

On Sun, Feb 14, 2016 at 2:24 PM, jonetsu(a)teksavvy.com &lt;jonetsu(a)teksavvy.com&gt; wrote: In that case its a line output, and microphone input, which are different levels. So long as they're both the same level, no problem. For the Art USB Dual Pre, just a normal guitar jack lead: http://openavproductions.com/loopback_cable.jpg jack_iodelay is "just" a JACK client. You connect it to whatever you want, in this case, we wish to measure the soundcard latency: 1) Patch RCA cable system-output-1 to system-input-one 2) connect jack_iodelay output to system:playback_1 3) connect jack_iodelay input to system:input_1 The *output* of jack_iodelay (it generates a sine-wave) gets played through the output of the audio interface, the analog signal is recorded again by the input, which is passed to jack_iodelays *input* port. jack_iodelay compares how many samples have passed since it sent that output, and can very accurately calculate how much time has passed. The resulting audio path of this setup: software playback -> ADC -> DAC -> software record. Recording & playback with Ardour is: ADC -> software record -> software playback -> DAC. Note that the overall amount of work done is the same: its only in a different order. The latency measurement taken is the exact amount of latency you will experience when recording music. Hope that clears up exactly whats going on :) -Harry -- http://www.openavproductions.com

On Sun, Feb 14, 2016 at 11:05:43AM -0500, jonetsu(a)teksavvy.com wrote: These numbers lead to the conclusion that the total latency is 3 * period_time + 1.4 ms. Since you use -n 2, the 3 * probably means that you are using jack2 (aka jackdmp) without the sync option. If you use that option (or jack1) the latency will be one period time less. 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)

On Sun, 14 Feb 2016 11:53:12 -0500, jonetsu(a)teksavvy.com wrote: Simply add --sync, for example: [rocketmouse@archlinux ~]$ grep sync /home/music/arch2014.1/start.03.01 roxterm --tab -n "♪ jackd" -e "jackd --sync -Xalsarawmidi -dalsa -r48000 -p256" ; sleep 2

On Sun, 14 Feb 2016, jonetsu(a)teksavvy.com wrote: Just off the top of my head, that sounds wrong. The ice1712 in delta devices says the device latency is 1ms so a quick calc would be jack= 1.3 + ice = 1 + ice = 1 + jack = 1.3 all adds up to 4.7ms or so. It is possible that the 1ms latency for the ICE1712 is with the time of going through the multimixer as well and not connecting directly to the ADC/DAC. -- Len Ovens www.ovenwerks.net

On Sun, 14 Feb 2016 18:19:49 +0100 Ralf Mardorf &lt;ralf.mardorf(a)alice-dsl.net&gt; wrote: This is fine since it is set at 95. memlock is also unlimited. This is also OK. Now this might be the crucial point. rtirq is installed and the rtirq was modified to exclude anything but the sound card RTIRQ_NAME_LIST="snd_ice1712" And then ./rtirq start was executed, as indicated in an advice here and/or web page (sorry too many info at one time - can't complain though ! :) and that is the important point. By running 'rtirq start' the impression was given that there's no need to reboot. Which gave: % ./rtirq status PID CLS RTPRIO NI PRI %CPU STAT COMMAND 87 FF 90 - 130 0.0 S irq/8-rtc0 547 FF 90 - 130 1.2 S irq/18-snd_ice1 After a reboot it is: ./rtirq status PID CLS RTPRIO NI PRI %CPU STAT COMMAND 449 FF 90 - 130 0.7 S irq/18-snd_ice1 47 FF 50 - 90 0.0 S irq/9-acpi The other thing that was done is to set all scaling_governors to 'performance'. Not so sure if this changed anything and I haven't tested it yet. I have asked before about the scaling_governor since it is always mentioned during an Ardour install and I was left under the impression that I should not care about this. So. After a reboot, the ardour session plays OK. There can be a faint, very sparse crackling noise although no 'JackAudioDriver::ProcessGraphAsyncMaster: Process error' reported by jackd in the console jackd was launched, with both the '-p 128 and --sync' options. It is now quite good. I tried the setup with a few acoustic guitar lines and it is no longer a fight to record something ! As is, it si impressive. There may very well be some fine tunings to do. I would also like to clean up the notes I have taken and post a summary of the steps and a big thank you to everyone who helped ! Cheers.

On Sun, 14 Feb 2016 09:24:55 -0500, jonetsu(a)teksavvy.com wrote: Why do you want to do measurements, if this isn't your domain? Follow Len advices to reduce latency. There seldom is the need to measure the exact latency. On Sun, 14 Feb 2016 09:15:23 -0500, jonetsu(a)teksavvy.com wrote: Run sudo apt-get update && sudo apt-get install checkinstall then instead of running sudo make install try to use sudo checkinstall don't forget to remove all packages that belong to jackd, such as libjack-whatsoever, it's the policy of your distro to split upstream into several packages, then install the build package by sudo dpkg -i *.deb it might not work for jackd, but you could test it. However, there's no reason to test jackd before installing it, you always could remove it and reinstall the jackd related packages. Also consider to backup your install, so if you should make extreme mistakes, you could restore your install from the backup. If you need to use sudo make install then before doing this also remove all installed packages that belong to jackd, before doing it too and after "make install" don't forget to run sudo ldconfig Regards, Ralf

On Sun, 14 Feb 2016 16:15:40 +0100 Ralf Mardorf &lt;ralf.mardorf(a)alice-dsl.net&gt; wrote: What I would like to do, ideally, is to run the freshly-compiled jackd from the directory it was compiled, before making a 'make install'. Is this possible at all ?

On Sat, 13 Feb 2016, jonetsu(a)teksavvy.com wrote: Thats good, your card is in a good slot. do you have anything connected to the hw io while trying to export? the PA-jack bridge has been reported to cause trouble there. see if: pactl unload-module module-jackdbus-detect from a command line makes export work. Ardour's HW should correct themselves don't worry about thoses conenctions to hw. If you do build your own jackd, make sure to fully remove the installed version :) -- Len Ovens www.ovenwerks.net

PPS: Just a general note, you are aware, that if you compile software by yourself, you could run in soname issues and perhaps after installing upgrades some of this software needs to be compiled against new installed libs? I guess this unlikely will happen for an Ubuntu derivative, but you never know.

On Sat, 13 Feb 2016, jonetsu(a)teksavvy.com wrote: sudo apt-get install linux-lowlatency for a start. (I would imagine you have linux-generic right now) also install rtirq. As you are running a delta1010 (I think), sudo edit /etc/default/rtirq... the line that says: RTIRQ_NAME_LIST="something something" to: RTIRQ_NAME_LIST="snd_ice1712" Never run jackd as root. (you may not be able to run as a user after wards which, as someone else already said, you have to do in order to use it) speaking of jackd... if you used Software Centre to install it... sudo mv /etc/security/limits.d/audio.conf.disabled /etc/security/limits.d/audio.conf and probably add yourself to the audio group before loggin out and back in. (Software center does not install jackd correctly) If you have more than one PCI slot, and cat /proc/interrupts shows snd_ice1712 sharing an interrupt with something else you might try moving it to another slot (sharing with fasteoi* is ok it seems). people say it is worth while building a true realtime kernel by patching the mainline and rebuilding, but I have not done that, I do turn cron off while recording though as that seems to help... with a RT kernel that shouldn't be needed. Do change your CPU governor from OnDemand to Performance. Even running the cpu at the lowest speed possible (800Mhz normally) seems to work better than the faster OnDemand. So if you have trouble with heat (you shouldn't as you should not be doing 100% cpu load while doing audio) it is better to set the CPU governor to UserSpace and set the speed to a steady lower speed where temperature is ok. Do find out how to change "swappiness" to 10 rather than 60 so the kernel doesn't start preemptive swapping even though it is using less than half your RAM :P If you want to run Jack really low (16/2 or 32/2) it may be worthwhile turning hyperthreading off. I have found a difference at those latencies, but not at 64/2 which is normally good enough. That is the short list, I may have missed something. Finally, the ice1712 based AIs like you have are able to do 1-2ms monitoring. If you are hearing delay, you are not using HW monitoring. Some of the input signal is going through your recording chain as well. Or to put it another way you are not _just_ using HW monitoring. I have made this mistake often enough to know :) -- Len Ovens www.ovenwerks.net

On Sun, 14 Feb 2016 14:33:32 +0000 John Murphy &lt;rosegardener(a)freeode.co.uk&gt; wrote: The system runs 3.13.0-24-generic (Linux Mint 17 original). The software management tool shows a same lowlatency kernel, so that's OK.

What does it mean for a soundcard to provide hardware monitoring?  And when you monitor a recording, don't you want to hear a signal coming from the DAW instead of bypassing it or something?  I'm just generally confused about what is meant by HW monitoring :D. On Sat, 2016-02-13 at 23:31 +0100, Ralf Mardorf wrote:

On Sat, 2016-02-13 at 20:17 -0600, Brett McCoy wrote: Perhaps we should add, that this does not work for virtual synths, or if the musician is dependent to hear the long-sustain-over-overdrive-delay- wah-wah-virtual-amp-plug-in during the recording. A hardware monitoring done by a sound card or by a mixing console allows to hear the already recorded tracks + the signal of what you want to record directly, so you can monitor already recorded virtual synth and already recorded guitars using the long-sustain-over-overdrive-delay-wah-wah-virtual-amp-plug-in, but you cannot monitor virtual synth and such guitar plugins without latency during recording them. You only can monitor the clean guitar signal and external synths without latency while recording them and after that, when playing hear the guitar + plug-ins and virtual synth.

On Sun, 14 Feb 2016 13:37:03 +0000, Fons Adriaensen wrote: Doing it this way latency doesn't matter. I suspect that several users experience issues, since they can not do it this way, because they need to play a virtual synth during recording or because they need virtual effects during recording, IOW hardware monitoring by the sound card or by a mixing console can't be used. That is one of my arguments why a "studio in the box" is _not equal to_, _let alone better than_ a studio with external gear. One other issue could be caused by chains of digital gear, they might have digital connections, but then sync could be tricky, or much more common for home studios, they all have their own analog ins and outs and inaudible latency of one device becomes a serious issue as soon as it's the sum of three devices, each with an inaudible latency, but all together with a much too long latency. To replace components or to buy analog replica or second-hand devices of old analog gear often is much more expensive, than buying digital emulations of those devices. The reason for this is not mistaken belief that real analog vintage devices are better, it's the sum of all features of vintage devices, compared to virtual digital devices/computer software that makes vintage devices de facto better. One advantage of such external gear is that even if the digital recording machine has got a very long latency, it doesn't matter, since by using hardware monitoring, there is no latency. You could apply what ever external effect you want while recording, with or without recording the effect and there is no latency and you do not need to care about how good your computer hardware is, simply use that much latency as needed to get no xruns.

On Mon, 15 Feb 2016 07:06:28 -0800 (PST) Len Ovens &lt;len(a)ovenwerks.net&gt; wrote: Regarding this, what is the role that jackd plays, with the -H --hwmon option ?

Am Montag, den 15.02.2016, 18:39 -0500 schrieb Paul Davis: Which one? Greets! Mitsch

your soundcard is supposed to be RTPRIO 80

On Sun, 14 Feb 2016, jonetsu(a)teksavvy.com wrote: That doesn't look right. I am not sure that changing this would fix your problem, but I prefer to have a different RTPRIO for anything above 50. Mine looks like: ~$ /etc/init.d/rtirq status PID CLS RTPRIO NI PRI %CPU STAT COMMAND 524 FF 90 - 130 0.8 S irq/17-snd_ice1 515 FF 85 - 125 0.0 S irq/19-snd_ens1 525 FF 80 - 120 0.8 S irq/46-snd_hda_ 47 FF 50 - 90 0.0 S irq/9-acpi 75 FF 50 - 90 0.0 S irq/20-ehci_hcd 76 FF 50 - 90 0.0 S irq/23-ehci_hcd 77 FF 50 - 90 0.0 S irq/41-xhci_hcd 79 FF 50 - 90 0.2 S irq/12-i8042 80 FF 50 - 90 0.0 S irq/1-i8042 82 FF 50 - 90 0.0 S irq/8-rtc0 (Yes three sound cards for testing) the line in /etc/default/rtirq looks like: RTIRQ_NAME_LIST="snd_ice1712 snd_ens snd eth0" eth0 does not show because it has not been loaded before this script has run on startup. It would be 75 if I rerun the script. Note I am not saying mine is right, but it seems to me I was told rtc0 does not have to right at the top. It hasn't caused me trouble, but I do very little MIDI work. -- Len Ovens www.ovenwerks.net

On Sun, 14 Feb 2016 17:42:01 -0500 &quot;jonetsu(a)teksavvy.com&quot; &lt;jonetsu(a)teksavvy.com&gt; wrote: Most likely the RTC isn't used at all anymore, check how many times it has fired with "cat /proc/interrupts". One my system it fires exactly once during bootup. AFAIK, the only important configuration nowdays is to make sure that the soundcard (or usb hub is connected to) is executed first, then JACK (which automatically gives the priority of your audio processing threads). So I'd suggest to run the soundcard interrupt at a high priority, say 95-97 or so (leave 99 for the housekeeping threads). Then run JACK at 80 (which will run your audio processing threads at 75). -- Joakim

On Mon, 15 Feb 2016 08:49:49 -0500 &quot;jonetsu(a)teksavvy.com&quot; &lt;jonetsu(a)teksavvy.com&gt; wrote: Those are probably the main threads of the processes, try hitting 'H' to show the threads too. You might also enjoy htop, which I prefer to top. -- Joakim

On Mon, 15 Feb 2016 09:28:09 -0500 &quot;jonetsu(a)teksavvy.com&quot; &lt;jonetsu(a)teksavvy.com&gt; wrote: Are you sure that you have configured JACK to run with realtime at priority 80? Kind of looks like you are running it at 10, which would make your mixbus audio threads run at 5 less, that is at priority 5. Note that top normally shows realtime thread priorities as a negative value offset by 1 compared to what we refer to when we configure this. -- Joakim

On Mon, 15 Feb 2016 14:02:35 -0500 &quot;jonetsu(a)teksavvy.com&quot; &lt;jonetsu(a)teksavvy.com&gt; wrote: OK, just saw the -P option :) Now it becomes very important to know where the heck the parameters for launching jackd are hidden so that it can be started properly at boot. I cannot use qjackctl since right now the buffer size defined in qjackctl is 128 while clearly jackd is launched with -p256, from Somewhere Else.

On Mon, 15 Feb 2016 14:16:23 -0500 Paul Davis &lt;paul(a)linuxaudiosystems.com&gt; wrote: There's an obvious conflict in execution between the jackd that gets launched at boot with the -p256 option, and the stored configuration in qjackctl that shows buffer size 128. My suspicion goes around pulse audio since the pulse jack sink is activated. An emacs grep-find through all /etc/ and its subdirectories only reports two instances of the string 'jackd', in limits audio.conf and default.pa (that one being jackdbus). Still a mystery where jackd gets launched, where are the parameters stored. And, why aren't the qjackctl params observed (where would these be stored ?) The pulse jack sink allows use of, for instance vlc and firefox for audio output. Why would that be ?

On Mon, 15 Feb 2016 14:37:35 -0500 Paul Davis &lt;paul(a)linuxaudiosystems.com&gt; wrote: Yes, jackdbus is launched. OK, thanks. I modified it, restarted the system and now all the proper parameters are there. And the jack sink pulse. The latest modifications in qjackctl were not saved. It showed 128, jackd was launched with 256. I do not know where qjackctl fished out the 128 value to show in the GUI. Just about everything can be restarted. It might be a matter of defining 'standard way'. A few moments ago I stopped jackd, without taking care of stopping Mixbus 3.1. There were some edits not saved (not much as I save very often) and Mixbus would not save them when exiting, because jackd was gone. This is not likely to happen, that jackd goes away, although in such cases data should be saved nevertheless.

On Mon, 15 Feb 2016 14:37:35 -0500 Paul Davis &lt;paul(a)linuxaudiosystems.com&gt; wrote: On a related subject, I will have to build jackd from upstream sources. Is it possible to launch jackd from the directory it was built, before doing a 'make install' ?

On Mon, 15 Feb 2016, jonetsu(a)teksavvy.com wrote: Have to? I can not think of any distros so bad you "have to" build jack, even Ubuntu 14.04 is workable if broken and in that case there are PPAs with a known good version. I use the broken version from 14.04 BTW, the brokenness has not been that hard to work around. None of the problems you have stated seem to stem from that bug anyway. I would normally say ./jackd should do it fine. however, I do not know if it uses libjack which would normally be grabbed from the installed version. I am thinking that libjack is what clients use except I can think of places a backend might use some of the same calls. a long winded way of saying I don't really know. -- Len Ovens www.ovenwerks.net

On 02/15/2016 11:48 PM, jonetsu(a)teksavvy.com wrote: Easier is to use the Ardour's ALSA backend (or Dummy) for exporting. Then again this bug was fixed more than 2 years go upstream in jack2, so updating jackd is a good idea anyway. Just play it back and record the master bus output with "timemachine" or "jack_capture" or some other jack-audio recorder. best, robin

On Mon, 15 Feb 2016, jonetsu(a)teksavvy.com wrote: Have you tried doing: pactl unload-module module-jackdbus-detect do export pactl load-module module-jackdbus-detect -- Len Ovens www.ovenwerks.net

On Mon, 15 Feb 2016, jonetsu(a)teksavvy.com wrote: Jack is not launched at boot. It would not work if it was as it would be owned by root. PA does not start jackdbus, it just detects if it is running. Seeing jackdbus -auto as a process does not mean it is "runnning" BTW. run jack_control status to see. Do you have Cadence installed? it may start jackd (or jackdus) at session start (not boot). Yes it does, I use it here. At boot time means before session start, which means by some other user than you :) You may mean at session start which is different than at boot. Look for: /etc/xdg/autostart/cadence-session-start.desktop as a place this might happen. If that is so you should be starting and changing jack params in cadence not qjackctl. The Cadence autostart can be disabled by running Cadence and unchecking the box just below Stop on System tab. -- Len Ovens www.ovenwerks.net

On Mon, 15 Feb 2016 21:19:59 +0100, Ralf Mardorf wrote: My apologies, QjackCtl doesn't stop jackd, if it was started without QjackCtl, consider to use killall -9.

On Mon, 15 Feb 2016 16:26:59 -0500, jonetsu(a)teksavvy.com wrote: QjackCtl > Setup... > Misc > Save JACK audio server configuration to There you can enable to save the settings to .jackdrc, but those are not the settings used by QjackCtl, they are still in ~/.config/rncbc.org/QjackCtl.conf.

Am 15.02.2016 um 23:48 schrieb jonetsu(a)teksavvy.com: Am 15.02.2016 um 23:52 schrieb jonetsu(a)teksavvy.com: Am 15.02.2016 um 23:55 schrieb jonetsu(a)teksavvy.com: Hey, can you guys stop and collect your thoughts for a few minutes, hours or - god forbid - days before you write another email and spam the list? Chris

On 15 February 2016 at 21:34, Ralf Mardorf &lt;ralf.mardorf(a)alice-dsl.net&gt; wrote: IIRC they aren't the settings used by jackdbus either? I remember having difficulty with it ignoring that file and using the settings inside ~/.config/jack/conf.xml instead. I had QJackCtl set to not use DBus, but the client auto-start mechanism was using DBus - long time ago now so might no longer be the case, but that was the cause of more than a small amount of confusion! ;-) Best wishes, Neil -- Neil C Smith Artist : Technologist : Adviser http://neilcsmith.net Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org Digital Prisoners - interactive spaces and projections - www.digitalprisoners.co.uk

On Mon, 15 Feb 2016 14:21:10 -0500 &quot;jonetsu(a)teksavvy.com&quot; &lt;jonetsu(a)teksavvy.com&gt; wrote: Now we are cooking ;) Let's see how that works for you? -- Joakim

On Mon, 15 Feb 2016 20:22:05 +0100 Joakim Hernberg &lt;jhernberg(a)alchemy.lu&gt; wrote: The installed package in Linux Mint 17 is called jackd2. There is also a jackd package that is installed although that one is for all practical purposes empty - don't know why it's there. I would not mind so much to start it manually after each reboot, if only I also rely on the pulse jack sink that gets Magically (and that's with an uppercase 'M') started at boot, which enables the use of vlc, firefox for audio output and as such is convenient. Starting jackd from the command line works well, but no sink in sight !

On Mon, 15 Feb 2016 12:14:04 -0800 (PST), Len Ovens wrote: IIUC the OP experience issues when using QjackCtl. FWIW QjackCtl > Setup... > Misc > Enable D-Bus interface (could be enabled or disabled)

On Mon, 15 Feb 2016 22:29:23 +0100 Ralf Mardorf &lt;ralf.mardorf(a)alice-dsl.net&gt; wrote: It is started by OS default. This said, I must say I have no idea what jackdbus is for. dbus I think is some kind of messaging system, perhaps like Corba (which I have developed for). I presume dbus allows jack_control (or any other app) to talk with jackd.

On 02/16/2016 11:10 AM, Hermann Meyer wrote: Nice. A related thing which might be nice to add for jack1 users: #!/bin/sh alsa_request_device --pid $! Audio0 & exec jackd -d alsa -d hw:0 That will not suspend pulseaudio, but instead tell PA to release the specific device only (and connect to jack instead if the pa-jack module is installed) for as long as jackd is running. https://github.com/x42/alsa_request_device best, robin

On Mon, 15 Feb 2016 08:49:49 -0500, jonetsu(a)teksavvy.com wrote: Since this is an issue for many users and it's better to quote messages and scripts without wrapping, I don't reply off-list. You seems to use Claws: In the editor Window, in the menu "Edit" chose > "Special paste" > "Unwrapped", let alone that you also could disable "Auto wrapping" in the same menu, but the latter would affect the complete email body. Alternatively, if you quote and you don't continue editing, then simply undo one time, this will undo the wrapping, but it gets lost assumed you continue editing, so it's better to use "Special paste". For Evolution users: In the editor window right beside the "Plain text" box, there's a box showing "Normal", for unwrapped quotes of terminal output chose "Performatted", after hat switch back to "Normal". I suspect that all modern MUAs provide an option to temporarily disable wrapping for plain text mails. Regards, Ralf

On Mon, 15 Feb 2016 10:07:51 -0500, jonetsu(a)teksavvy.com wrote: If the receiving end does use a broken MUA your way wouldn't solve the issue either. You don't need to copy and paste, to temporarily use an external editor add an action: Configuration > Actions... > Menu name: Editor emacs Command: roxterm --hide-menubar -n "emacs" -e emacs %f You could use any other terminal too or if you're using a GUI version of emacs no terminal at all, just add "%f" behind the command to launch the editor. Select an email and use emacs by Tools > Actions > Editor emacs