14.09.2012, 16:29, "Colin Guthrie" :
> Adding kludges and work arounds
> is not going to make anything "better". It might make things "work" but
> that really depends on how you define "working".
Absolutely agree. But it is a matter of resources == years of waiting for.
Everybody wants to have wo
'Twas brillig, and Вечный Студент at 13/09/12 11:30 did gyre and gimble:
> 13.09.2012, 02:08, "Lennart Poettering" :
>
>> Hmm, weird. I'd recommend pinging the ALSA folks about this. If
>> the control device doesn't work while the udev rules are executed
>> this sounds like a driver bug and should
13.09.2012, 02:08, "Lennart Poettering" :
> Hmm, weird. I'd recommend pinging the ALSA folks about this. If the
> control device doesn't work while the udev rules are executed this
> sounds like a driver bug and should be fixed in the kernel!
I'm not sure all drivers writers are ready to fit t
On Wed, 12.09.12 22:03, Вечный Студент (student...@yandex.ru) wrote:
>
> 11.09.2012, 16:17, "Colin Guthrie" :
> > For the avoidance of doubt, I have no idea if this specific card does
> > require fireware or not - this was a "could be one of these" suggestions
> > I was throwing into the melting
11.09.2012, 16:17, "Colin Guthrie" :
> For the avoidance of doubt, I have no idea if this specific card does
> require fireware or not - this was a "could be one of these" suggestions
> I was throwing into the melting pot.
>
> The original reporter can maybe confirm if firmware is involved - I
> th
'Twas brillig, and Lennart Poettering at 11/09/12 13:12 did gyre and gimble:
> On Tue, 11.09.12 11:15, Colin Guthrie (gm...@colin.guthr.ie) wrote:
>
Yes, thanks, sleeping does help (the card under question is the second
one, i.e. with suffix '1'):
~ $ cat /etc/udev/rules.d/99-
On Tue, 11.09.12 11:15, Colin Guthrie (gm...@colin.guthr.ie) wrote:
> >> Yes, thanks, sleeping does help (the card under question is the second
> >> one, i.e. with suffix '1'):
> >>
> >> ~ $ cat /etc/udev/rules.d/99-zlocal.rules | grep alsa
> >> ACTION=="add", SUBSYSTEM=="sound", KERNEL=="control
'Twas brillig, and Lennart Poettering at 11/09/12 02:12 did gyre and gimble:
> On Mon, 03.09.12 14:34, Вечный Студент (student...@yandex.ru) wrote:
>
>>
>> 03.09.2012, 13:48, "Colin Guthrie" :
>>> Then you should probably try and debug this further - e.g. by rmmod'ing
>>> the module and inserting
On Mon, 03.09.12 14:34, Вечный Студент (student...@yandex.ru) wrote:
>
> 03.09.2012, 13:48, "Colin Guthrie" :
> > Then you should probably try and debug this further - e.g. by rmmod'ing
> > the module and inserting it and trying to work out why it's not run. You
> > can always replace the rule wi
03.09.2012, 22:40, "Colin Guthrie" :
> I would lean towards this being a kernel problem or some other rule in
> place which invalidates the action (e.g. perhaps it's restored but a
> latter call issues an "alsactl init 1").
>
> I don't know enough about udev or kernel side of things to really say
>
'Twas brillig, and Вечный Студент at 03/09/12 11:34 did gyre and gimble:
> 03.09.2012, 13:48, "Colin Guthrie" :
>> Then you should probably try and debug this further - e.g. by rmmod'ing
>> the module and inserting it and trying to work out why it's not run. You
>> can always replace the rule with
03.09.2012, 13:48, "Colin Guthrie" :
> Then you should probably try and debug this further - e.g. by rmmod'ing
> the module and inserting it and trying to work out why it's not run. You
> can always replace the rule with one that runs a script instead that
> writes debugging info or similar.
>
> In
[ Please don't drop the list from the CC ]
'Twas brillig, and Вечный Студент at 03/09/12 10:33 did gyre and gimble:
> 03.09.2012, 13:05, "Colin Guthrie" :
>> Yes this unit is just a part of a two part solution here. See the
>> commit where it was introduced for an explanation:
>>
>> http://git.a
'Twas brillig, and Вечный Студент at 02/09/12 15:48 did gyre and gimble:
> In accordance with
>
> ~ $ cat /etc/modprobe.d/alsa.conf
> options snd slots=snd-hda-intel,snd-hdsp,snd-usb-audio
>
> I have three sound cards. The second one's state (snd-hdsp) isn't restored
> after booting up (say, S
On 02.09.2012 20:17, Zbigniew Jędrzejewski-Szmek wrote:
> In general it is not possible to predict when the sound cards will
> appear in the system. Maybe they are connected over USB and the user
> will plug them in one hour after start. So synchronizing to fixed
> point in the boot sequence is gu
On Sun, Sep 02, 2012 at 08:03:46PM +0400, Вечный Студент wrote:
> > Are you sure the sound cards are initialized by the time systemd tries
> > to call your service? If no, you must synchronize with udev (or just
> > order the service to a later time).
>
> I'm not sure as far as I'm not an author o
> Are you sure the sound cards are initialized by the time systemd tries
> to call your service? If no, you must synchronize with udev (or just
> order the service to a later time).
I'm not sure as far as I'm not an author of the service file: it is supplied by
alsa-utils Arch Linux package (and
On Sun, Sep 2, 2012 at 4:48 PM, Вечный Студент wrote:
> In accordance with
>
> ~ $ cat /etc/modprobe.d/alsa.conf
> options snd slots=snd-hda-intel,snd-hdsp,snd-usb-audio
>
> I have three sound cards. The second one's state (snd-hdsp) isn't restored
> after booting up (say, Sample Clock Source par
In accordance with
~ $ cat /etc/modprobe.d/alsa.conf
options snd slots=snd-hda-intel,snd-hdsp,snd-usb-audio
I have three sound cards. The second one's state (snd-hdsp) isn't restored
after booting up (say, Sample Clock Source parameter is set to default 48 KHz
rather to AutoSync). Starting 'a
19 matches
Mail list logo
