[PlanetCCRMA] problem on fedora 10, CCRMA, jack and terratec 22

Fernando Lopez-Lezcano nando at ccrma.Stanford.EDU
Mon Nov 16 15:10:46 PST 2009


On Mon, 2009-11-16 at 23:18 +0100, Gabriel wrote:
> On Sat, Nov 14, 2009 at 05:53:46PM -0800, Fernando Lopez-Lezcano wrote:
> > On Sun, 2009-11-15 at 00:28 +0100, Gabriel wrote:
> > > On Sat, Nov 14, 2009 at 10:48:24AM -0800, Fernando Lopez-Lezcano wrote:
> > > > On Sat, 2009-11-14 at 01:58 +0100, linux at gabriel-striewe.de wrote:
> > > > > Hello,
> > > > > 
> > > > > I have just today started using CCRMA. I installed the distribution
> > > > > using your installation notes (installing fedora 10, yum update,
> > > > > adding ccrma repo, installing ccrma).
> > > > > 
> > > > > According to lspci, my soundcard is:
> > > > > 
> > > > > 00:06.0 Multimedia audio controller: VIA Technologies Inc. VT1720/24
> > > > > [Envy24PT/HT] PCI Multi-Channel Audio Controller (rev 01)
> > > > > 
> > > > > Now, when I start jack using "jackd -R -dalsa", every few minutes I
> > > > > get the error:
> > > > > 
> > > > > ALSA: poll time out, polled for 31999959 usecs
> > > > > JackAudioDriver::ProcessAsync: read error, skip cycle
> > > > > 
> > > > > And when in qjackctl I try to connect audio system input to output, it
> > > > > doesn't do anything, just in the shell window in which I started jack:
> > > > > 
> > > > > JackGraphManager::Connect already connected port_src = 1 port_dst = 3
> > > > > JackGraphManager::Connect already connected port_src = 2 port_dst = 4
> > > > > 
> > > > > which seems strange to me, since it doesn't show the connections in
> > > > > qjackctl.
> > > > > 
> > > > > cat /proc/asound/cards says:
> > > > > 
> > > > > 0 [ICE1724        ]: ICE1724 - ICEnsemble ICE1724
> > > > >                       ICEnsemble ICE1724 at 0xe800, irq 17
> > > > > 
> > > > > I hope those error messages can give you a hint about what is
> > > > > wrong. If there is any other output I can give you, please help..
> > > > 
> > > > Hmmmm, strange. The error message would suggest some sort of ALSA (the
> > > > sound driver) problem. Does it happen only once?
> > > > 
> > > > What happens if you use different parameters?
> > > >   jackd -R -d alsa -d hw:0 -p 1024 -n 3
> > > > 
> > > > You can also try starting jack from within qjackctl (set the parameters
> > > > in the "Setup" tab. Then press the "Start" button and check the messages
> > > > in the "Messages" pane. Start a simple jack client like Hydrogen, load
> > > > one of the demo patterns and connect the audio outputs in qjackctl to
> > > > the system outputs. You might need to tweak input/output levels in
> > > > alsamixer (or better yet, in envy24control - but I don't remember if
> > > > 1724 based cards are supported). 
> > > 
> > > Hello, thanks for that. Today I took away my ICE1724 card and replaced
> > > it with my old VIA card, as I mentioned in my earlier message
> > > today. However, during the week I will come back to this issue. I just
> > > for today didn't want into issues concerning having two sound cards in
> > > the system.
> > > 
> > > However, I ran into one other problem. If I log onto my system
> > > directly, locally, I log on, and then I start jack with jackd -R -d
> > > alsa -d hw:0 -p 1024 -n 3 without problems. I do have a kernel bug,
> > > this one:
> > > 
> > > Kernel failure message 1:
> > > BUG: sleeping function called from invalid context IRQ-14(412) at arch/x86/mm/highmem_32.c:8
> > > in_atomic():0 [00000000], irqs_disabled():1
> > > Pid: 412, comm: IRQ-14 Not tainted 2.6.26.8-1.rt16.1.fc10.ccrma.i686.rt #1
> > >  [<c041fe47>] __might_sleep+0xe8/0xed
> > >  [<c041cd75>] kmap+0x42/0x55
> > >  [<c0504250>] sg_copy_buffer+0xa6/0x16c
> > >  [<c0504323>] sg_copy_to_buffer+0xd/0xf
> > >  [<f88c9409>] atapi_qc_complete+0x25c/0x2b6 [libata]
> > >  [<f88c35b5>] __ata_qc_complete+0x8e/0x93 [libata]
> > >  [<f88c4211>] ata_qc_complete+0x197/0x19d [libata]
> > >  [<f88cf999>] ata_hsm_qc_complete+0x9b/0xb3 [libata]
> > >  [<f88cffb3>] ata_sff_hsm_move+0x602/0x64e [libata]
> > >  [<c04233f0>] ? finish_task_switch+0x4b/0xf0
> > >  [<c06446c1>] ? __rt_spin_lock+0x24/0x61
> > >  [<f88d025e>] ata_sff_interrupt+0x153/0x1eb [libata]
> > >  [<c04609a4>] handle_IRQ_event+0x49/0xe6
> > >  [<c0460e03>] do_irqd+0x12b/0x229
> > >  [<c0460cd8>] ? do_irqd+0x0/0x229
> > >  [<c043aa9b>] kthread+0x3b/0x61
> > >  [<c043aa60>] ? kthread+0x0/0x61
> > >  [<c0405803>] kernel_thread_helper+0x7/0x10
> > > 
> > > However, it doesn't hinder jack and the other apps like qjackctl and
> > > hydrogen from running. 
> > 
> > It is a knows issue with that particular kernel. You can safely ignore
> > the message (there are newer kernels in the planetccrma-testing
> > repositories you could try). 
> > 
> > > If I log in through ssh -Y from my Lapton
> > > running Debian 5.0, it gives me the message:
> > > 
> > > could not open driver .so '/usr/lib/jack/jack_firewire.so': libffado.so: cannot open shared object file: No such file or directory
> > > could not open component .so '/usr/lib/jack/jack_firewire.so': libffado.so: cannot open shared object file: No such file or directory
> > > jackdmp 1.9.2
> > > Copyright 2001-2005 Paul Davis and others.
> > > Copyright 2004-2008 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
> > > JACK server starting in realtime mode with priority 10
> > > creating alsa driver ... hw:0|hw:0|1024|3|48000|0|0|nomon|swmeter|-|32bit
> > > control open "hw:0" (Permission denied)
> > > Cannot initialize driver
> > > no message buffer overruns
> > > JackServer::Open() failed with -1
> > > Failed to start server
> > > 
> > > This does not happen, if I log onto my computer locally (the one which
> > > is actually running jack) and then log on through ssh. In that case, I
> > > can use the jack apps through ssh without problems. If then, I log off
> > > again locally, I have the same problem, so it is reproducable.
> > > 
> > > 
> > > What do I do to be able to log in through ssh?
> > 
> > For security external logins are not allowed access to the audio devices
> > by default, only the logged in user in the main console can use them (so
> > if you are logged in locally, and the remote user is the same things
> > also work). 
> > 
> > In fc10 this is controlled through the "policy kit". For example, from a
> > terminal:
> > 
> > ----
> > $ polkit-action --action org.freedesktop.hal.device-access.sound
> > action_id:        org.freedesktop.hal.device-access.sound
> > description:      Directly access sound devices
> > message:          System policy prevents access to the sound devices
> > default_any:      no
> > default_inactive: no
> > default_active:   yes
> > ----
> > 
> > which means an active session (ie: local login) has access, everyone
> > else does not have access. 
> > 
> > You can use polkit-gnome-authorization (a gui application) to make
> > changes. Look for "Directly access sound devices" and change things so
> > that "Anyone" has access. 
> > 
> Thanks for your help. I just wanted to note that this still didn't
> work by default. 

You mean access to audio devices of a remotely logged in user? That is
by design and normally not needed or wanted. 

> Fedora (at least version 10 which I am using) sets
> the group of the audio devices to root by default. If however, I chgrp
> the audio devices to a group of which I am a member (chgrp -R
> audio /dev/snd* and chgrp -R audio /proc/asound/*), then everything
> works fine.

If you are in the proper group, of course. 

> Just wanted to note that for documentation purposes.

The chgrp will work, of course, or even a chmod 666 for them, but only
until the next reboot (I think). If you want to use that workaround you
will have to add something to the (for example) /etc/rc.d/rc.local. 

Authorization for audio devices uses acl's in addition to plain unix
permissions. To see who currently has access to the audio devices do:

  getfacl /dev/snd/*

You will see that while the plain unix device permissions are going to
show up as root.audio for the audio devices, the _actual_ access
permissions due to acl's (Access Control Lists) is wider and includes
the currently logged in user (when there is someone logged in, of
course). 

The proper thing to do is to update the policy kit authorization for
them as outlined above. 

-- Fernando




More information about the PlanetCCRMA mailing list