[PlanetCCRMANews] RME9652 problems aggravated by kde update

Fernando Lopez-Lezcano nando at ccrma.Stanford.EDU
Wed Apr 6 16:12:14 PDT 2011


On 04/06/2011 02:40 PM, Craig Bourne wrote:
> A few days ago, in the midst of testing to document the existing level
> of audio support on my system following an earlier report of problems, I
> applied the most recent set of KDE updates after which my system was silent.
>
> The only exception being that both the firefox and chrome the browser
> rendered audio as expected when browsing multimedia files.
>
> My first attempt at a repair (as I awaited advice from queries off this
> list) came as a result of noting that in recent posts it was now
> considered counterproductive to specify the hardware device to <<insert
> name of ALSA client application here>> and this set me to thinking about
> the information that I had been taught, over the past several years, to
> convey to JACK when invoking it (as in "-d hw 0:0").

Let's see:

Jack: definitely DO use hw:xxx for starting jack. Always.

ALSA applications that are not jack aware (which ones do you use??): 
well, it depends on what you want them to use. Using "default" as the 
device will pipe output through PA. Could be good or not depending on 
the application and your needs. If you specify the soundcard directly 
then it might not work as PA may be using it already (Jack has special 
code that asks PA for the card).

In short, always use Jack if possible.

BTW, the best way to tell jack which soundcard to use would be to use 
its name, for example in the laptop I'm typing this I can find the name 
by doing:

----
$ cat /proc/asound/cards
  0 [Intel          ]: HDA-Intel - HDA Intel
                       HDA Intel at 0xf2420000 irq 32
  1 [NVidia         ]: HDA-Intel - HDA NVidia
                       HDA NVidia at 0xcdefc000 irq 16
29 [ThinkPadEC     ]: ThinkPad EC - ThinkPad Console Audio Control
                       ThinkPad Console Audio Control at EC reg 0x30, fw 
6MHT38WW-1.13
----

If I want to use the onboard sound I would do this (minimalistic options):

----
$ jackd -R -d alsa -d hw:Intel
jackdmp 1.9.6
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2010 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
JACK server starting in realtime mode with priority 60
audio_reservation_init
Acquire audio card Audio0
creating alsa driver ... 
hw:Intel|hw:Intel|1024|2|48000|0|0|nomon|swmeter|-|32bit
Using ALSA driver HDA-Intel running on card 0 - HDA Intel at 0xf2420000 
irq 32
configuring for 48000Hz, period = 1024 frames (21.3 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 32bit integer little-endian
ALSA: use 2 periods for capture
ALSA: final selected sample format for playback: 32bit integer little-endian
ALSA: use 2 periods for playback
Using port names patch v0.1 (07.04.2010)
----

and then jack starts normally.
So in this case the card to use is "hw:Intel". No need to eliminate this 
(in fact you need it for best performance - if you use "default" it is 
very likely that jack will go though Pulse Audio which is NOT a good 
choice).

If you do that, what does jack PRINT when it fails to start (I'm 
assuming your problem is that jack did not start, you are not telling us 
that explicitly).

So, if you try to start jack, what does it print?
It is important to (please) include detailed information if you 
need/want help. When you say:

> I then restarted the system and found that I again had sound in the
> first few applications tested.

Which applications? What configuration were they started with? How did 
they fail in the first place? We don't really know from the information 
you send us so it is impossible to tell what the real fix might be. It 
does not look to me like what you did to the PA configuration is a 
proper fix.

-- Fernando


> As I eliminated this from the options I also noted that on the QjackCtl
> menu of Misc options there was one marked "Enable D-Bus interface" which
> was unchecked. Since, from our previous discussion, this was the magic
> sauce for coordination with Pulseaudio (which I had earlier assumed was
> causing problems) I checked this box.
>
> The immediate results at this level was, that while still not able to
> hear sound from the system, lsof showed that files were no longer being
> held open by knotify preventing normal operation of jackd.
>
> --
> Stage 2:
>
>
> Because it appeared to me that Pulseaudio did not seem to be using
> sensible defaults (gleaned from several sources including error output
> of more than a few audio programs) I today I had a look at
> /etc/pulse/default.pa
>
> There I made the following 4 changes (tagged in the extracted lines):
>
>     ### Load audio drivers statically (it's probably better to not load
>     ### these drivers manually, but instead use module-hal-detect --
>     ### see below -- for doing this automatically)
>     load-module module-alsa-sink ###Uncommented
>     load-module module-alsa-source device=hw:1,0 ###Uncommented
>     #load-module module-oss device="/dev/dsp" sink_name=output
>     source_name=input
>     #load-module module-oss-mmap device="/dev/dsp" sink_name=output
>     source_name=input
>     load-module module-null-sink ###Uncommented
>     load-module module-pipe-sink ###Uncommented
>



More information about the PlanetCCRMANews mailing list