No sound in rawhide

[Paul F. Johnson]

Hi,

Prior to the big push to f12, my system had full audio. No problems.
Lovely, lovely sounds.

For some reason, alsa and pulseaudio are completely failing to pick up
my sound card (either the onboard one or my soundblaster). This is
despite them both being listed on lspci and lsmod.

Any ideas on getting this to work again?

TTFN

Paul

[Ralf Ertzinger]

Hi.

On Mon, 15 Jun 2009 13:09:27 +0100, Paul wrote:
> Any ideas on getting this to work again?

On my system all sound files (/dev/snd) were owned by root instead of the
user logged into X. Don't know who's responsible for fixing that.

[drago01]

On Mon, Jun 15, 2009 at 4:23 PM, Ralf Ertzinger wrote:
> Hi.
>
> On Mon, 15 Jun 2009 13:09:27 +0100, Paul wrote:
> > Any ideas on getting this to work again?
>
> On my system all sound files (/dev/snd) were owned by root instead of the
> user logged into X. Don't know who's responsible for fixing that.

ConsoleKit / hal

[Bastien Nocera]

On Mon, 2009-06-15 at 13:09 +0100, Paul wrote:
> Hi,
>
> Prior to the big push to f12, my system had full audio. No problems.
> Lovely, lovely sounds.
>
> For some reason, alsa and pulseaudio are completely failing to pick up
> my sound card (either the onboard one or my soundblaster). This is
> despite them both being listed on lspci and lsmod.
>
> Any ideas on getting this to work again?

As per usual, pulseaudio debug output is a requirement.

[Kjartan Maraas]

ti., 16.06.2009 kl. 11.17 +0100, skrev Bastien Nocera:
> On Mon, 2009-06-15 at 13:09 +0100, Paul wrote:
> > Hi,
> >
> > Prior to the big push to f12, my system had full audio. No problems.
> > Lovely, lovely sounds.
> >
> > For some reason, alsa and pulseaudio are completely failing to pick up
> > my sound card (either the onboard one or my soundblaster). This is
> > despite them both being listed on lspci and lsmod.
> >
> > Any ideas on getting this to work again?
>
> As per usual, pulseaudio debug output is a requirement.

I found that pulseaudio -k && pulseaudio "fixed" it for me after chown
on /dev/snd/* which had root.audio ownership. I see this error when
starting pulseaudio though:

[kmaraas@nc6400 ~]$ pulseaudio
E: bluetooth-util.c: Error from ListAdapters
reply:org.freedesktop.DBus.Error.ServiceUnknown

Cheers
Kjartan

[Lennart Poettering]

On Wed, 17.06.09 13:51, Kjartan Maraas ([e-mail]) wrote:
> ti., 16.06.2009 kl. 11.17 +0100, skrev Bastien Nocera:
> > On Mon, 2009-06-15 at 13:09 +0100, Paul wrote:
> > > Hi,
> > >
> > > Prior to the big push to f12, my system had full audio. No problems.
> > > Lovely, lovely sounds.
> > >
> > > For some reason, alsa and pulseaudio are completely failing to pick up
> > > my sound card (either the onboard one or my soundblaster). This is
> > > despite them both being listed on lspci and lsmod.
> > >
> > > Any ideas on getting this to work again?
> >
> > As per usual, pulseaudio debug output is a requirement.
>
> I found that pulseaudio -k && pulseaudio "fixed" it for me after chown
> on /dev/snd/* which had root.audio ownership. I see this error when
> starting pulseaudio though:

Hmm, if the permissions aren't set up correctly then this is some HAL
ACL handling brokeness. Wouldn't be the first one.
> [kmaraas@nc6400 ~]$ pulseaudio
> E: bluetooth-util.c: Error from ListAdapters
> reply:org.freedesktop.DBus.Error.ServiceUnknown

That's a missing bluetoothd. This shouldn't be fatal though, or is it?

Lennart

[Bastien Nocera]

On Wed, 2009-06-17 at 13:51 +0200, Kjartan Maraas wrote:
> ti., 16.06.2009 kl. 11.17 +0100, skrev Bastien Nocera:
> > On Mon, 2009-06-15 at 13:09 +0100, Paul wrote:
> > > Hi,
> > >
> > > Prior to the big push to f12, my system had full audio. No problems.
> > > Lovely, lovely sounds.
> > >
> > > For some reason, alsa and pulseaudio are completely failing to pick up
> > > my sound card (either the onboard one or my soundblaster). This is
> > > despite them both being listed on lspci and lsmod.
> > >
> > > Any ideas on getting this to work again?
> >
> > As per usual, pulseaudio debug output is a requirement.
>
> I found that pulseaudio -k && pulseaudio "fixed" it for me after chown
> on /dev/snd/* which had root.audio ownership. I see this error when
> starting pulseaudio though:
>
> [kmaraas@nc6400 ~]$ pulseaudio
> E: bluetooth-util.c: Error from ListAdapters
> reply:org.freedesktop.DBus.Error.ServiceUnknown

That means that bluetoothd isn't running, which should be fine. There
are some known problems with PulseAudio's Bluetooth plugin handling of
presense/absence of bluetoothd.

This was discussed in another thread on this ML.

Cheers

[Ray Van Dolson]

On Wed, Jun 17, 2009 at 01:51:37PM +0200, Kjartan Maraas wrote:
> ti., 16.06.2009 kl. 11.17 +0100, skrev Bastien Nocera:
> > On Mon, 2009-06-15 at 13:09 +0100, Paul wrote:
> > > Hi,
> > >
> > > Prior to the big push to f12, my system had full audio. No problems.
> > > Lovely, lovely sounds.
> > >
> > > For some reason, alsa and pulseaudio are completely failing to pick up
> > > my sound card (either the onboard one or my soundblaster). This is
> > > despite them both being listed on lspci and lsmod.
> > >
> > > Any ideas on getting this to work again?
> >
> > As per usual, pulseaudio debug output is a requirement.
>
> I found that pulseaudio -k && pulseaudio "fixed" it for me after chown
> on /dev/snd/* which had root.audio ownership. I see this error when
> starting pulseaudio though:
>
> [kmaraas@nc6400 ~]$ pulseaudio
> E: bluetooth-util.c: Error from ListAdapters
> reply:org.freedesktop.DBus.Error.ServiceUnknown
>
> Cheers
> Kjartan

Hmm, I just always figured I was supposed to add myself to the audio
group.  So these files are supposed to be owned by my local user
account when I log in eh?

Ray

[Jef Spaleta]

On Wed, Jun 17, 2009 at 7:25 AM, Ray Van Dolson wrote:
> Hmm, I just always figured I was supposed to add myself to the audio
> group.  So these files are supposed to be owned by my local user
> account when I log in eh?

No...  you should be added to the acl list associated to the device if
you are the physical console user as per the authorization policy
managed by PolicyKit.  This it how it works from at least F10 onward.
Mucking around with file ownership directly is "old think." The system
scripts associated with pam use to do that on user login and
logout...but has been replaced with the more flexible solution
involving acls that PolicyKit based hardware access authorization
makes use of.

for example on the F10 system I'm on right now:
ls -la /dev/snd/seq
crw-rw----+ 1 root root 116, 3 2009-06-17 07:07 /dev/snd/seq

getfacl /dev/dsp
# file: dev/snd/seq
# owner: root
# group: root
user::rw-
user:myuser:rw-
group::rw-
mask::rw-
other::---

I do not own the file in the traditional Unix permissions sense. But I
am listed in the acl list with read write access.  If your user is not
in the acl list, something misfired in the area of the PolicyKit based
authorization handling.

-jef

[Jef Spaleta]

On Wed, Jun 17, 2009 at 8:06 AM, Jeff Spaleta wrote:
> getfacl /dev/dsp

typo:
that should have been .dev./snd/seq not /dev/dsp

the getfacl output cut and paste was correct for /dev/snd/seq

-jef

[Ray Van Dolson]

On Wed, Jun 17, 2009 at 08:06:36AM -0800, Jeff Spaleta wrote:
> On Wed, Jun 17, 2009 at 7:25 AM, Ray Van Dolson wrote:
> > Hmm, I just always figured I was supposed to add myself to the audio
> > group.  So these files are supposed to be owned by my local user
> > account when I log in eh?
>
> No...  you should be added to the acl list associated to the device if
> you are the physical console user as per the authorization policy
> managed by PolicyKit.  This it how it works from at least F10 onward.
> Mucking around with file ownership directly is "old think." The system
> scripts associated with pam use to do that on user login and
> logout...but has been replaced with the more flexible solution
> involving acls that PolicyKit based hardware access authorization
> makes use of.
>
> for example on the F10 system I'm on right now:
> ls -la /dev/snd/seq
> crw-rw----+ 1 root root 116, 3 2009-06-17 07:07 /dev/snd/seq
>
> getfacl /dev/dsp
> # file: dev/snd/seq
> # owner: root
> # group: root
> user::rw-
> user:myuser:rw-
> group::rw-
> mask::rw-
> other::---
>
> I do not own the file in the traditional Unix permissions sense. But I
> am listed in the acl list with read write access.  If your user is not
> in the acl list, something misfired in the area of the PolicyKit based
> authorization handling.

Good to know.  I've checked the acl list in the past and definitely
wasn't a member.

I'll have to remove myself from audio and see if I can track this down.

Thanks,
Ray

[Kjartan Maraas]

on., 17.06.2009 kl. 11.44 -0700, skrev Ray Van Dolson:
> On Wed, Jun 17, 2009 at 08:06:36AM -0800, Jeff Spaleta wrote:
> > On Wed, Jun 17, 2009 at 7:25 AM, Ray Van Dolson wrote:
> > > Hmm, I just always figured I was supposed to add myself to the audio
> > > group.  So these files are supposed to be owned by my local user
> > > account when I log in eh?
> >
> > No...  you should be added to the acl list associated to the device if
> > you are the physical console user as per the authorization policy
> > managed by PolicyKit.  This it how it works from at least F10 onward.
> > Mucking around with file ownership directly is "old think." The system
> > scripts associated with pam use to do that on user login and
> > logout...but has been replaced with the more flexible solution
> > involving acls that PolicyKit based hardware access authorization
> > makes use of.
> >
> > for example on the F10 system I'm on right now:
> > ls -la /dev/snd/seq
> > crw-rw----+ 1 root root 116, 3 2009-06-17 07:07 /dev/snd/seq
> >
> > getfacl /dev/dsp
> > # file: dev/snd/seq
> > # owner: root
> > # group: root
> > user::rw-
> > user:myuser:rw-
> > group::rw-
> > mask::rw-
> > other::---
> >
> > I do not own the file in the traditional Unix permissions sense. But I
> > am listed in the acl list with read write access.  If your user is not
> > in the acl list, something misfired in the area of the PolicyKit based
> > authorization handling.
>
> Good to know.  I've checked the acl list in the past and definitely
> wasn't a member.
>
> I'll have to remove myself from audio and see if I can track this down.

Did you find anything? I'm still seeing this problem with rawhide as of
today.

Cheers
Kjartan

[Sachin]

i added myself to the pulse-access and audio group ..

On Wed, Jul 8, 2009 at 7:43 AM, Kjartan Maraas  wrote:
> on., 17.06.2009 kl. 11.44 -0700, skrev Ray Van Dolson:
> > On Wed, Jun 17, 2009 at 08:06:36AM -0800, Jeff Spaleta wrote:
> > > On Wed, Jun 17, 2009 at 7:25 AM, Ray Van Dolson
>
> wrote:
> > > > Hmm, I just always figured I was supposed to add myself to the audio
> > > > group.  So these files are supposed to be owned by my local user
> > > > account when I log in eh?
> > >
> > > No...  you should be added to the acl list associated to the device if
> > > you are the physical console user as per the authorization policy
> > > managed by PolicyKit.  This it how it works from at least F10 onward.
> > > Mucking around with file ownership directly is "old think." The system
> > > scripts associated with pam use to do that on user login and
> > > logout...but has been replaced with the more flexible solution
> > > involving acls that PolicyKit based hardware access authorization
> > > makes use of.
> > >
> > > for example on the F10 system I'm on right now:
> > > ls -la /dev/snd/seq
> > > crw-rw----+ 1 root root 116, 3 2009-06-17 07:07 /dev/snd/seq
> > >
> > > getfacl /dev/dsp
> > > # file: dev/snd/seq
> > > # owner: root
> > > # group: root
> > > user::rw-
> > > user:myuser:rw-
> > > group::rw-
> > > mask::rw-
> > > other::---
> > >
> > > I do not own the file in the traditional Unix permissions sense. But I
> > > am listed in the acl list with read write access.  If your user is not
> > > in the acl list, something misfired in the area of the PolicyKit based
> > > authorization handling.
> >
> > Good to know.  I've checked the acl list in the past and definitely
> > wasn't a member.
> >
> > I'll have to remove myself from audio and see if I can track this down.
>
> Did you find anything? I'm still seeing this problem with rawhide as of
> today.
>
> Cheers
> Kjartan
>
> --
> fedora-devel-list mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Sachin]

also renamed file /etc/pulse/default.pa.rpmnew to /etc/pulse/default.pa

On Wed, Jul 8, 2009 at 8:22 AM, Sachin  wrote:
> i added myself to the pulse-access and audio group ..
>
> On Wed, Jul 8, 2009 at 7:43 AM, Kjartan Maraas wrote:
> > on., 17.06.2009 kl. 11.44 -0700, skrev Ray Van Dolson:
> > > On Wed, Jun 17, 2009 at 08:06:36AM -0800, Jeff Spaleta wrote:
> > > > On Wed, Jun 17, 2009 at 7:25 AM, Ray Van Dolson
> >
> > wrote:
> > > > > Hmm, I just always figured I was supposed to add myself to the audio
> > > > > group.  So these files are supposed to be owned by my local user
> > > > > account when I log in eh?
> > > >
> > > > No...  you should be added to the acl list associated to the device if
> > > > you are the physical console user as per the authorization policy
> > > > managed by PolicyKit.  This it how it works from at least F10 onward.
> > > > Mucking around with file ownership directly is "old think." The system
> > > > scripts associated with pam use to do that on user login and
> > > > logout...but has been replaced with the more flexible solution
> > > > involving acls that PolicyKit based hardware access authorization
> > > > makes use of.
> > > >
> > > > for example on the F10 system I'm on right now:
> > > > ls -la /dev/snd/seq
> > > > crw-rw----+ 1 root root 116, 3 2009-06-17 07:07 /dev/snd/seq
> > > >
> > > > getfacl /dev/dsp
> > > > # file: dev/snd/seq
> > > > # owner: root
> > > > # group: root
> > > > user::rw-
> > > > user:myuser:rw-
> > > > group::rw-
> > > > mask::rw-
> > > > other::---
> > > >
> > > > I do not own the file in the traditional Unix permissions sense. But I
> > > > am listed in the acl list with read write access.  If your user is not
> > > > in the acl list, something misfired in the area of the PolicyKit based
> > > > authorization handling.
> > >
> > > Good to know.  I've checked the acl list in the past and definitely
> > > wasn't a member.
> > >
> > > I'll have to remove myself from audio and see if I can track this down.
> >
> > Did you find anything? I'm still seeing this problem with rawhide as of
> > today.
> >
> > Cheers
> > Kjartan
> >
> > --
> > fedora-devel-list mailing list
> > [e-mail]
> > https://www.redhat.com/mailman/listinfo/fedora-devel-list