no sound

I also have a now sound problem with an NVidia card. Here's where I am....

1) PulseAudio is disabled. (Not shown in ps ax, and volume control reports it cannot connect to the server)

2) Moved KDE settings away from alsa device hw:2.7

3) mplayer will use alsa device hw:2.7 and plays just fine.

4) if I start jackd on alsa hw:2.7 while mplayer is using it, jackd reports device is in use.

5) If I start jackd without mplayer running, jackd starts just fine and mplayer then reports the device is in use.

6) jackd creates a system playback sink.

7) Now, with 'mplayer -ao jack x.mp3' jack creates a mplayer source and maps it to the system sink.

8) No sound. Alsamixer reports no applications are playing audio.

9) if I run qjackrec, jackd will map the mplayer source to both the system and qjackreq sinks. qjackreq captures the audio into a .wav file just fine, but still no audio output. After jackd is shutdown, mplayer will play qjackrec's .wav file (via alsa, again on hw:2.7).

10) All the while jackd is running, including the period mplayer is playing into jack, alsamixer reports that no applications are playing sound.

I'm stumped. Alsa works, the alsa device works, jackd works, jackld takes ownership of the propoer alsa device... and nothing.

On Wed, 11 Sep 2013, Bill Kirkpatrick wrote:

> I also have a now sound problem with an NVidia card. Here's where I
> am....
>
> 1) PulseAudio is disabled. (Not shown in ps ax, and volume control
> reports it cannot connect to the server)

ok

> 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.

> 3) mplayer will use alsa device hw:2.7 and plays just fine.

> 4) if I start jackd on alsa hw:2.7 while mplayer is using it, jackd
> reports device is in use.

good.

> 5) If I start jackd without mplayer running, jackd starts just fine and
> mplayer then reports the device is in use.

good.

> 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? Are you running jackd or jackdbus?
(both are shipped in the jackd2 package) What do the logs say? How are you
seeing the logging output of jack?

> 7) Now, with 'mplayer -ao jack x.mp3' jack creates a mplayer source and
> maps it to the system sink.

How are you seeing the system sink? with what command or application?

> 8) No sound. Alsamixer reports no applications are playing audio.

The alsamixer I know does not report if sound is being played or not, only
control levels. Alsa itself does not report connections. What application
are you using to see this? If you have disabled pulse, the output level
may be down. If you run alsamixer in a terminal can you turn all the
levels up, are any channels muted?

> 9) if I run qjackrec, jackd will map the mplayer source to both the
> system and qjackreq sinks. qjackreq captures the audio into a .wav file
> just fine, but still no audio output. After jackd is shutdown, mplayer
> will play qjackrec's .wav file (via alsa, again on hw:2.7).

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.

> 10) All the while jackd is running, including the period mplayer is
> playing into jack, alsamixer reports that no applications are playing
> sound.

Alsamixer does not report connections like pulse does or pavucontrol or
the kde mixer (also a pulse controler).

Sent via email for easier quoting.

>> 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...

Geez... And Grandma really supposed to be able to use Linux on her desktop?

I found this...

http://www.sabi.co.uk/Notes/linuxSoundLatency.html

It is really old (2004) and claims to be incomplete at that. But, it is what fixed the problem...

>>>>>
System: tweaking the PCI latency timers
    PCI devices share the bus, and the “latency timer” for each device determines for how many consecutive cycles the device can use the bus. Devices with a high value for the latency timer can and do cause gaps in sound. Often enough it is video cards that have high default latency timer values, to look better in benchmarks. It is possible to reset the default value of the latency timer with the command:

    setpci -v -s '*:*' latency_timer=20
    setpci -v -s '0:0' latency_timer=0

    which sets it to 32 cycles and resets the latency timer to 0 for the host bridge, usually with id 00:00.0 (to prevent bad performance for DMA). It is possible and perhaps useful to give a larger value to a sound device, for example with one of:

    setpci -v -d '1102:0002' latency_timer=80
    setpci -v -s '00:09.0' latency_timer=80

    where 1102:0002 is the manufacturer and model id of your sound card, or 00:09.0 is the PCI bus id of the same card. It will be different on your system, so use lspci and/or lspci -n to discover them.
    Usually it is better to use the manufacturer and model id instead of the bus id, as moving the card from one slot to another is more common than replacing the a sound card with another in the same slot.
    Note that sometimes setting too low a value for the latency of the video card might make video card operations less visually smooth; setting the latency timer of the host bridge to greater than zero can significantly impact the transfer rate of DMA.
    There is more information on this issue in this general introduction to PCI latency, or this PCI latency HOWTO, and this Linux specific PCI latency article.
<<<<

Yep, Gramps, it's really quite simple, you see. You just get your sound device;s bus id and set latency timers for everything else to some lowish value you pulled right out of your butt. Then you set the sound device to some higher-ish value you also pulled out of your butt. Oh, and don't forget to configure your boot process...

Sorry for the sarcasm, but really guys?

Len, thank you very much for your help. Once the PCI timers were mangled everything has worked exactly as expected. I'm not an audio pro, so I appologize for using the wrong termanology around sources and sinks. Jack seems to have a bad rap, it is actually quite useful to the average Joe (Although Grandma did throw both me and the computer out of the house :) ) All I really wanted in the end was a good equalizer, as I end up with a headache after about an hour of listening to streaming mp3 music services.

Jackd, with Pulseaudio on top, and the Calf plugin pack, has given me that and really far more than I could have imagined. More sliders, buttons, and knobs than a human should be allowed to play with. Quite great, actually.

If you have any pull with the jackd team(s), I ran into only one very small annoyance. When a patchbay is active, jackd insists on creating a new automatic link to the system playback when an application port defined in that patchbay conneccts/reconnects. Thus putting the patched connections in parallel with the original stream. Reproduce using a VLC playlist and an activated patchbay where VLC is a defined "Readable Client/Output Port". Every song will trigger a new direct link to the system playback port, constantly putting everything back in parallel with the patchbay processing.

My guess at a "best fix" would be for jackd to not create any automatic patches if a patchbay is active and a port in that patchbay appears/connects on the system (a port already in Connection window of qjackctl will be used). If it has to draw a new, previously non-exsistant port instance, in the Connections window then, yes, make the automatic connection. The workaround is surely easy enough, I just tell everything to use Pulse and patch things in using Pulse's more persistant connection.

Whops, instead of "Connections Window" in qjackctl above, I should have said Patchbay window. Ports defined in the patchbay, but currently not being used, aren't shown in the Connections window.

On Wed, September 11, 2013 7:02 pm, Bill Kirkpatrick wrote:
> Len, thank you very much for your help. Once the PCI timers were
> mangled everything has worked exactly as expected. I'm not an audio

Older machine then, PCIe slots are all set to 0. Glad it worked for you.

> pro, so I appologize for using the wrong termanology around sources and

Not a problem at all.

> sinks. Jack seems to have a bad rap, it is actually quite useful to the
> average Joe (Although Grandma did throw both me and the computer out of
> the house :) ) All I really wanted in the end was a good equalizer, as
> I end up with a headache after about an hour of listening to streaming
> mp3 music services.

Anyone who actually does much (semi)pro-audio in Linux, likes jack. It
does take some getting used to.

> If you have any pull with the jackd team(s), I ran into only one very

I don't. I wish I could code well enough to help is all.

> small annoyance. When a patchbay is active, jackd insists on creating a
> new automatic link to the system playback when an application port
> defined in that patchbay conneccts/reconnects. Thus putting the patched
> connections in parallel with the original stream. Reproduce using a VLC

That would not be jack, but the application connecting to jack. It is
normally considered correct not to auto connect, but on the other hand, a
user not used to the jack world expects when they start an application it
will just make sound. Most serious users would prefer some kind of session
management instead. (there are a number out there)

For a really bad example of auto connect... Audacious connects left to all
Odd channels and right to all even... sure makes a mess of things when you
have 10 or more output channels.

Anyway, I think this bug could be made invalid.

--
Len Ovens
www.OvenWerks.net