>> 2) Moved KDE settings away from alsa device hw:2.7 > >not sure what that would(n't) do as I am not too familiar with kde,but it >makes sense. Just to make sure that nothing is, even in the least bit, is interested in device hw:2.7 >> 6) jackd creates a system playback sink. > >Not quite the terminology I am used to with jack, but assuming same as >pulse, good. >Question: how are you starting jack? jackd from a terminal. >Are you running jackd or jackdbus? jackd >(both are shipped in the jackd2 package) What do the logs say? How are you >seeing the logging output of jack? At the terminal. Looks like this: bill@dvr-1:~$ /usr/bin/jackd -T -R -ndefault -d alsa -P hw:2,7 -r 44100 jackdmp 1.9.10 Copyright 2001-2005 Paul Davis and others. Copyright 2004-2013 Grame. jackdmp comes with ABSOLUTELY NO WARRANTY This is free software, and you are welcome to redistribute it under certain conditions; see the file COPYING for details no message buffer overruns no message buffer overruns no message buffer overruns JACK server starting in realtime mode with priority 10 audio_reservation_init Acquire audio card Audio0 Acquire audio card Audio2 creating alsa driver ... hw:2,7|-|1024|2|44100|0|0|nomon|swmeter|-|32bit configuring for 44100Hz, period = 1024 frames (23.2 ms), buffer = 2 periods ALSA: final selected sample format for playback: 32bit integer little-endian ALSA: use 2 periods for playback ^CJack main caught signal 2 Released audio card Audio0 Released audio card Audio2 audio_reservation_finish JackTemporaryException : now quits... bill@dvr-1:~$ Note: "^C" is my keying Control-C to shut it down. > How are you seeing the system sink? with what command or application? patchage > If you run alsamixer in a terminal can you turn all the levels up, are any channels muted? No channels muted, all at 100% > So it appears, audio is getting to jack just fine and jack is sending the > signal on. However jack does not control output levels, that has to be > done manually. Running alsamixer from a terminal is the most surefire way > of knowing you are dealing with the right controls. Use F6 to select your > hw:2.7 sounds card. Did the whole alsamixer thing, F6 and all. All was well. Continuing to play after I posted, I happened to start Audacity while everything was wired up and "playing" (not). Once Audacity opened, there was a short 3-4 second burst of sound, followed by more silence. The process repeated itself, with intermittent periods of sound/silence. I noticed (on patchage) that during the silence the system was racking up dropouts. During the sound playing periods dropouts stopped counting up. So I went off looking in dropouts. I had already established my account has both realtime and memlock permissions. When I started playing with all this, jackd was reporting that it could not accomplish these two functions, and no longer is reporting the warnings since I fixed the permissions. At least jackd seems to think realtime and memlock are good now. The system is an nearly idle i5@3.3Gh and 32Gb of memory. CPU load is near zero, with or without realtime scheduling. The test audio file being played into jack by mplayer is read off a SSD. The system hasn't actually swapped anything, at all, since I've owned it. I've played with jack's periods/buffers, -S, and such and not much changed for the better, although I can surely make the dropouts worse using these parameters, but never better enough to produce useful sound. And, I always have to rely on Audacity to kick in any sound at all.