Hi Len and David, David, yes, that script will create a pulse sink/source (this used to happen automagically when I started jack from Qjackctl, but does not now). Even with it started, no sound comes out the speakers. (Interestingly, I have an hdmi output on this laptop and if I select that as the playback device in Volume Control, it plays through the speakers on that monitor.) Len, I checked alsamixer and all seems ok. It appears I've got the setup of the onboard audio totally messed up...and I have no idea what is missing. :( It's like built in audio is turned off. On Sun, Jun 3, 2018 at 9:51 AM, Len Ovens <len(a)ovenwerks.net> wrote:

As I said, I checked it, nothing is muted and all are at 100%. What am I missing... On Sun, Jun 3, 2018 at 10:51 AM, David Kastrup <dak(a)gnu.org> wrote:

On Sun, Jun 3, 2018 at 11:07 AM, David Kastrup <dak(a)gnu.org> wrote: Lost count... :(

On Sun, 3 Jun 2018, Mac wrote: Ok, simple things first. have you verified with meterbridge or something similar, that there is audio (needle movement) going to the system output ports? Have you tried connecting your audio source to all audio outputs? -- Len Ovens www.ovenwerks.net

On Sun, 3 Jun 2018, Mac wrote: Cool, that narrows things down anyway. So there is sound in Jackdbus, but the output is not getting to the hardware. It looks to me that whatever jackd has saved needs to be cleared out. jack_control ds alsa dps capture none dps playback none jack_control dps device hw:0 dps rate 44100 dps period 128 dps nperiods 2 start See if that works. The first line is the important one. So long as capture and playback are set separately, device doesn't seem to take effect (for me anyway). In any case you have three different devices in there and one would probably work better. You may have to replace the hw:0 with something better (hw:0 is probably hw:PCH). I don't know what HD2 is, but if you have all external audio unplugged I don't think it should be there. -- Len Ovens www.ovenwerks.net

On Mon, 4 Jun 2018, Mac wrote: jackdbus and jackd work differently. Jackd saves the last used commandline and if used without any parameters will use that commandline. So using a new commandline kills the old one. Jackdbus is different. It stores all of the parameters and will reload them at next run. It will only change things that the user changes but the old values stay. With your other audio device you had set period to 64 in the past and I have found that is too small for many internal audio devices (I have one that using 64 crashes jack) so I went one up. If all you are doing is listening, I would suggest that you use 1024 as that would use less resources. In Qjackctl terms, period is the same as "Frames/Period" and nperiods is the same as "Periods/Buffer". Internal audio devices are designed for A) listening to games noise and youtube, B) for using skype. The outputs sound reasonably good... the mic inputs, not so much (good enough for skype). The design "low latency" for internal devices is 30ms. If they manage at least that low they are "good enough" anything lower is accidental. jackdbus stores device (for a device that is both input and output) as well as input device and output device. It seems that if all are set, odd things happen. So in any script I use to start jackdbus, I clear the ones I am not using. I am not sure what qjackctl does, but I get the idea that rather than use device, it gives the same device to both input and output. That way the same code can deal with both the same or different values for each. In your original output from jack_control I noticed that device as well as input and output were set, that is why the line that set them to none so that there would be no confusion. -- Len Ovens www.ovenwerks.net

On Mon, 4 Jun 2018, Mac wrote: :) I wuld not (and do not) change any system settings as this will produce errors when pulse is upgraded by apt. I personally would start the script with: killall -9 jackd jackdbus That gets rid of any jack processes started by someone else. Next thing is that you need to move the jack_control start line to the end of your jack_control lines otherwise the settings after that will not be used. So: #!/bin/bash killall -9 jackd jackdbus jack_control ds alsa dps capture none dps playback none jack_control dps device hw:PCH jack_control dps rate 48000 jack_control dps nperiods 2 jack_control dps period 256 jack_control start Then I remove pulse's connection to anything alsa: pactl unload-module module-udev-detect pactl unload-module module-alsa-card Those two lines mean that the only output pulse can find is jack and so pulse defaults to the jack bridge all the time. Removing any path to an alsa device also allows jack to run in freewheel mode without crashing because pulse will try to use an alsa device for sync :P In my case, I also unload the jackdetect module because I want my jack-pa bridge to be specific: pactl unload-module module-jackdbus-detect Then in place of the above module I do: pactl load-module module-jack-sink client_name=PulseOut channels=2 connect=no pactl load-module module-jack-source client_name=PulseIn channels=2 connect=no I use the connect=no because my outputs are not always 1 and 2 they may be 9 and 10 if I am using s/pdif. Then I use jack_connect to connect what ports I do want jack_connect system:capture_1 PulseIn:front-left jack_connect system:capture_2 PulseIn:front-right jack_connect PulseOut:front-left system:playback_9 jack_connect PulseOut:front-right system:playback_10 I have shown one config only in my case the last line might look more like: jack_connect PulseOut:front-right ${device}:playback_${o_port_r} (well actually most of the above lines would have variables inserted) -- Len Ovens www.ovenwerks.net

On Tue, 5 Jun 2018, Mac wrote: ... Good. The script does use these labels: We told pulse to create two jack clients: PulseIn and PulseOut. Pulse named the ports front-left and front-right. You can see these ports by looking at qjackctl's Connections window or by typing jack_lsp in a terminal. playback-1/-2 are again jack ports, but in this case they are created by the jack backend or master device rather than a client. So they are called "system:*" However, aside from that, they can be treated like the ports from any other client. aplay is an alsa utility and so does not show jack ports, jack_lsp will show jack ports (both audio and midi). system will show only one device. If you are sure they are all in sync, it may be possible to create an alsa multi virtual card... see: https://alsa.opensrc.org/TwoCardsAsOne http://www.jrigg.co.uk/linuxaudio/ice1712multi.html and others. The second link above gives some of the troubles that may be encountered with this method. However, this is the only way to get them all to be "system:" ports. There is another way to do the same thing that seems to be (in my experience) more robust. I use zita-ajbridge in the form of zita-a2j for inputs and zita-j2a for outputs. Zita-ajbridge does not care if the devices are synced or not. However, in this case the port client will have a different name besides system. I normally choose the name of the device: zita-j2a -j PCH,1-out -d hw:PCH,1 -r 44100 -p 128 -n 2 & this gives me a port like: PCH,1-out:playback_1 Now, when you mention using suround, I also realize you would want your pulse-jack bridge to have more than 2 ports. So you would change the channels=value to 4,5 or 6 depending on how many channels you need in the: pactl load-module module-jack-sink client_name=PulseOut channels=2 connect=no line. Pulse will conveniently label them in suround like terms. (jack and zita will assume a multi channel audio card meant for mutitrack recording where channels are used as a number of mono sources) zita-j2a will also allow more than two channels with the -c parameter. It is ok to use a large number here as zita-j2a will only use as many ports as there are actual DACs. The whole thing is really very much like connecting a group of stereo componants together. each program or utility is like a box. Jack shows the plugs on each box and you use a (virtual) wire to connect the boxes as you wish. The maker of each box decides what to label their plugs and the owner is expected to figure out what they want to do with them. -- Len Ovens www.ovenwerks.net

On Tue, 5 Jun 2018, Mac wrote: I do not know if jack will accept surround71:PCH,0 for device. I do not know the mechanism by which it switches either. You are getting beyond my knowledge. It would not hurt to try. The other thing to look at may be hdajackretask. This shows what the audio jacks are currently being used for. I do not know if changing "blue Line In" to "Rear Side" will change hw:HDA from 2.0 to 4.0 for example. but it may be worth a try. Setting physical jacks to do surround operation may be all it takes. In my case the real answer is I don't know. I tend to disable any internal audio device to clear up one more thing that may interfere with "real audio". -- Len Ovens www.ovenwerks.net

On Tue, Jun 5, 2018 at 3:20 PM, Len Ovens <len(a)ovenwerks.net> wrote: Apparently not. I tried "jack_control dps device surround71:PCH,0" and still got playback_1,_2. (There are also surround21, 41, etc. none of those changed anything either.) As for hdajackretask, when I tried to "Apply now" I got a device busy message. I didn't try "Install boot override". Agreed, when in my studio or at a venue where I have "real audio". But, sitting in my hotel room or elsewhere, with only my laptop and it's internal hardware...one must improvise. ;) (Not saying I would need more than 2 outputs in such a case, that's just a "hey, the thing has more than two channels, how do get to them" musing.)

On Wed, Jun 6, 2018 at 10:22 AM, Bill Purvis <bill(a)billp.org> wrote: Assuming the 'L" was a typo i changed the lines in the script to: jack_control dps device surround71:PCH,0 jack_control dps channels 7 That produced the following error after attempting execute the second line: DBus exception: org.jackaudio.Error.InvalidArgs: Invalid container address 'driver':'channels':'(null)' supplied to method 'GetParameterInfo'. A look at the jack_control help showed the parameter was "outchannels: Number of playback channels (defaults to hardware max) (uint:notset:0:0)" I assume this means the surround71 knows only 2 channels, but I changed the script: jack_control dps device surround71:PCH,0 jack_control dps outchannels 7 This does not throw an error, but still only results in 2 system outputs.

Update to the last post...if I plug in the headphones before I run the script, the headphones. but if I unplug them the speakers don't come on. On Wed, Jun 6, 2018 at 1:31 PM, Mac <macdroid53(a)gmail.com> wrote:

Yep, that's what was. I forgot alsa is still there. :( On Wed, Jun 6, 2018 at 1:44 PM, Len Ovens <len(a)ovenwerks.net> wrote:

On Sun, Jun 3, 2018 at 9:51 AM, Len Ovens <len(a)ovenwerks.net> wrote: ​Alas, not true. ​ Alsamixer does precisely that (with no arguments) on my system where the default ALSA device is Pulse. ​

On Sun, 3 Jun 2018 06:51:01 -0700 (PDT) Len Ovens <len(a)ovenwerks.net> wrote: And a look at pavucontrol for anything pulse related.