[pulseaudio-discuss] New kernel 2.6.34-rc4, no audio

Colin Guthrie gmane at colin.guthr.ie
Mon Apr 19 09:29:26 PDT 2010


'Twas brillig, and Gene Heskett at 19/04/10 16:24 did gyre and gimble:
> On Monday 19 April 2010, Colin Guthrie wrote:
>> 'Twas brillig, and Gene Heskett at 19/04/10 05:10 did gyre and gimble:
>>> And
>>> [root at coyote linux-2.6.34-rc3]# getfacl /dev/snd/controlC0
>>> getfacl: Removing leading '/' from absolute path names
>>> # file: dev/snd/controlC0
>>> # owner: root
>>> # group: audio
>>> user::rw-
>>> user:gene:rw-
>>
>> ^^^^^^^^^^^^^^^
>>
>>> group::rw-
>>> mask::rw-
>>> other::---
>>>
>>> ???
>>>
>>> Teach please, thanks.
>>>
>> :)
>>
>> Todays Lesson:
>>
>> You can see your user sneaking in there. This means that your user does
>> have permission to read and write this node.
>>
>> So now that this is set, you should try running PA again and see if you
>> get the "accessible: no" bit in the log.
>>
>> Col
> 
> Not sure if I am, and since the only way to run it again is to kill and 
> restart it with the '-vvv &' options , I'll wait for the next reboot, which 
> is coming at some point today, because if I restart it without a working 
> knotify4, the sound results are all chopped up.  knotify4 goes away shortly 
> after the boot because 10 minutes later its still hogging one core of my 
> phenom at 100% so I kill it.  But that is also true of the distro kernels.

We used to have a 100% CPU issue with knotify a while back in Mdv, but I
thought we'd fixed it. It relates to how Phonon works with streams. All
the backends are broken in one way or the other :(. IIRC tho' knotify
does some strange things with it's sound output... It never bothered me
quite enough to get my hands dirty and look at the code however. I've
seen it hogging the alsa hw:0 device in the past tho'. Nasty.

The problem with waiting until reboot is that the ACLs for the device
nodes may not be written correctly at boot time for whatever reason, and
it's this boot that causes the problems. Running PA manually after
checking the ACLs is a good way to verify everything is setup correctly.


> I am finding enough wrong with mandriva that I'm considering bailing for the 
> *buntu camp, or if I can survive till F13 is final, maybe that, the beta is 
> working on my lappy including the 3d stuff. 

If you're a KDE man (which is sounds like you are) then MAndriva and
OpenSuse generally get the best write ups for KDE related stuff.

> MDV's dkms is busted

Works fine here, perhaps it's specific dkms packages?

> ccache's installer dates from 2005 so it doesn't work,

Hmm, I have ccache running fine here too.

> makes a kernel build take 2 hours on a 4 core phenom

Are you building an RPM via mandriva's packages because if so, you are
aware that it's building several separate kernels for various different
purposes. You can edit the SPEC to not generate all the sundray kernels
and only build the one you are interested in.

> and a host of other quibbles, like an almost 
> complete lack of expert assistance from its "expert" mailing list (english 
> version), yadda yadda.

Hmm, strange. I don't really subscribe to the expert list much... cooker
tends to be what interests me more.

You should hang out in IRC. People tend to be pretty helpful generally.

> Expert support on this list is the one shining star in this otherwise dismal 
> sky.  Thank you very much.

No worries.

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]




More information about the pulseaudio-discuss mailing list