[alsa-devel] [RFC PATCH] alsactl: Do not run udev rule before datadir is mounted
The 90-alsa-restore.rules udev rule is primarily meant to handle hotplugging, but sometimes it is also run before /usr is mounted, and alsactl restore depends on /usr/share/alsa being present.
If /usr/share/alsa is not present, we're so early in the boot process that alsa-restore.service (or upstart equivalent) will run later on.
BugLink: https://bugs.launchpad.net/bugs/1289730 Signed-off-by: David Henningsson david.henningsson@canonical.com ---
I'm not really sure of all quirks in the boot process, and I haven't tested the patch either, hence the RFC above. Do you think it makes sense? Should we also add @sbindir@ to the things to test for?
alsactl/90-alsa-restore.rules.in | 2 +- alsactl/Makefile.am | 1 + configure.ac | 1 + 3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/alsactl/90-alsa-restore.rules.in b/alsactl/90-alsa-restore.rules.in index c68119d..c83c6b5 100644 --- a/alsactl/90-alsa-restore.rules.in +++ b/alsactl/90-alsa-restore.rules.in @@ -1,4 +1,4 @@ -ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS!="card*", GOTO="alsa_restore_go" +ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS!="card*", TEST=="@datadir@", GOTO="alsa_restore_go" GOTO="alsa_restore_end"
LABEL="alsa_restore_go" diff --git a/alsactl/Makefile.am b/alsactl/Makefile.am index b862412..afbedb3 100644 --- a/alsactl/Makefile.am +++ b/alsactl/Makefile.am @@ -44,6 +44,7 @@ endif
edit = \ $(SED) -r -e 's,@sbindir@,$(sbindir),g' \ + -e 's,@datadir@,$(mydatadir),g' \ -e 's,@daemonswitch@,$(ALSACTL_DAEMONSWITCH),g' \ < $< > $@ || rm $@
diff --git a/configure.ac b/configure.ac index 7e6894a..a4d2db3 100644 --- a/configure.ac +++ b/configure.ac @@ -292,6 +292,7 @@ AC_DEFINE_UNQUOTED(SOUNDSDIR, "$soundsdir", [directory containing sample data])
mydatadir="$dir/alsa" AC_DEFINE_UNQUOTED(DATADIR, "$mydatadir", [directory containing alsa configuration]) +AC_SUBST(mydatadir)
AC_ARG_WITH(testsound, AS_HELP_STRING([--with-testsound=file], [give the path of test sound file for alsaconf]),
Date 13.6.2014 10:15, David Henningsson wrote:
The 90-alsa-restore.rules udev rule is primarily meant to handle hotplugging, but sometimes it is also run before /usr is mounted, and alsactl restore depends on /usr/share/alsa being present.
If /usr/share/alsa is not present, we're so early in the boot process that alsa-restore.service (or upstart equivalent) will run later on.
BugLink: https://bugs.launchpad.net/bugs/1289730 Signed-off-by: David Henningsson david.henningsson@canonical.com
I'm not really sure of all quirks in the boot process, and I haven't tested the patch either, hence the RFC above. Do you think it makes sense?
Yes, I think that's ok. Takashi?
Should we also add @sbindir@ to the things to test for?
It shouldn't harm anything. Could you prepare a new patch?
alsactl/90-alsa-restore.rules.in | 2 +- alsactl/Makefile.am | 1 + configure.ac | 1 + 3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/alsactl/90-alsa-restore.rules.in b/alsactl/90-alsa-restore.rules.in index c68119d..c83c6b5 100644 --- a/alsactl/90-alsa-restore.rules.in +++ b/alsactl/90-alsa-restore.rules.in @@ -1,4 +1,4 @@ -ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS!="card*", GOTO="alsa_restore_go" +ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS!="card*", TEST=="@datadir@", GOTO="alsa_restore_go" GOTO="alsa_restore_end"
LABEL="alsa_restore_go" diff --git a/alsactl/Makefile.am b/alsactl/Makefile.am index b862412..afbedb3 100644 --- a/alsactl/Makefile.am +++ b/alsactl/Makefile.am @@ -44,6 +44,7 @@ endif
edit = \ $(SED) -r -e 's,@sbindir@,$(sbindir),g' \
-e 's,@datadir\@,$(mydatadir),g' \diff --git a/configure.ac b/configure.ac index 7e6894a..a4d2db3 100644 --- a/configure.ac +++ b/configure.ac @@ -292,6 +292,7 @@ AC_DEFINE_UNQUOTED(SOUNDSDIR, "$soundsdir", [directory containing sample data])
mydatadir="$dir/alsa" AC_DEFINE_UNQUOTED(DATADIR, "$mydatadir", [directory containing alsa configuration]) +AC_SUBST(mydatadir)
AC_ARG_WITH(testsound, AS_HELP_STRING([--with-testsound=file], [give the path of test sound file for alsaconf]),
On 2014-06-13 10:26, Jaroslav Kysela wrote:
Date 13.6.2014 10:15, David Henningsson wrote:
The 90-alsa-restore.rules udev rule is primarily meant to handle hotplugging, but sometimes it is also run before /usr is mounted, and alsactl restore depends on /usr/share/alsa being present.
If /usr/share/alsa is not present, we're so early in the boot process that alsa-restore.service (or upstart equivalent) will run later on.
BugLink: https://bugs.launchpad.net/bugs/1289730 Signed-off-by: David Henningsson david.henningsson@canonical.com
I'm not really sure of all quirks in the boot process, and I haven't tested the patch either, hence the RFC above. Do you think it makes sense?
Yes, I think that's ok. Takashi?
Should we also add @sbindir@ to the things to test for?
It shouldn't harm anything. Could you prepare a new patch?
Sure, please find it attached. I was also considering adding something under /var as well, but I didn't do that, because I think it will fall back to an "alsactl init" in that case (right?), so it still makes some sense to run alsactl without /var.
alsactl/90-alsa-restore.rules.in | 2 +- alsactl/Makefile.am | 1 + configure.ac | 1 + 3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/alsactl/90-alsa-restore.rules.in b/alsactl/90-alsa-restore.rules.in index c68119d..c83c6b5 100644 --- a/alsactl/90-alsa-restore.rules.in +++ b/alsactl/90-alsa-restore.rules.in @@ -1,4 +1,4 @@ -ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS!="card*", GOTO="alsa_restore_go" +ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS!="card*", TEST=="@datadir@", GOTO="alsa_restore_go" GOTO="alsa_restore_end"
LABEL="alsa_restore_go" diff --git a/alsactl/Makefile.am b/alsactl/Makefile.am index b862412..afbedb3 100644 --- a/alsactl/Makefile.am +++ b/alsactl/Makefile.am @@ -44,6 +44,7 @@ endif
edit = \ $(SED) -r -e 's,@sbindir@,$(sbindir),g' \
-e 's,@datadir\@,$(mydatadir),g' \diff --git a/configure.ac b/configure.ac index 7e6894a..a4d2db3 100644 --- a/configure.ac +++ b/configure.ac @@ -292,6 +292,7 @@ AC_DEFINE_UNQUOTED(SOUNDSDIR, "$soundsdir", [directory containing sample data])
mydatadir="$dir/alsa" AC_DEFINE_UNQUOTED(DATADIR, "$mydatadir", [directory containing alsa configuration]) +AC_SUBST(mydatadir)
AC_ARG_WITH(testsound, AS_HELP_STRING([--with-testsound=file], [give the path of test sound file for alsaconf]),
Date 13.6.2014 11:05, David Henningsson wrote:
On 2014-06-13 10:26, Jaroslav Kysela wrote:
Date 13.6.2014 10:15, David Henningsson wrote:
The 90-alsa-restore.rules udev rule is primarily meant to handle hotplugging, but sometimes it is also run before /usr is mounted, and alsactl restore depends on /usr/share/alsa being present.
If /usr/share/alsa is not present, we're so early in the boot process that alsa-restore.service (or upstart equivalent) will run later on.
BugLink: https://bugs.launchpad.net/bugs/1289730 Signed-off-by: David Henningsson david.henningsson@canonical.com
I'm not really sure of all quirks in the boot process, and I haven't tested the patch either, hence the RFC above. Do you think it makes sense?
Yes, I think that's ok. Takashi?
Should we also add @sbindir@ to the things to test for?
It shouldn't harm anything. Could you prepare a new patch?
Sure, please find it attached. I was also considering adding something under /var as well, but I didn't do that, because I think it will fall back to an "alsactl init" in that case (right?), so it still makes some sense to run alsactl without /var.
Yes, /var contents is not mandatory. Thanks, I applied it to the alsa-utils repository.
Jaroslav
At Fri, 13 Jun 2014 11:05:52 +0200, David Henningsson wrote:
On 2014-06-13 10:26, Jaroslav Kysela wrote:
Date 13.6.2014 10:15, David Henningsson wrote:
The 90-alsa-restore.rules udev rule is primarily meant to handle hotplugging, but sometimes it is also run before /usr is mounted, and alsactl restore depends on /usr/share/alsa being present.
If /usr/share/alsa is not present, we're so early in the boot process that alsa-restore.service (or upstart equivalent) will run later on.
BugLink: https://bugs.launchpad.net/bugs/1289730 Signed-off-by: David Henningsson david.henningsson@canonical.com
I'm not really sure of all quirks in the boot process, and I haven't tested the patch either, hence the RFC above. Do you think it makes sense?
Yes, I think that's ok. Takashi?
Should we also add @sbindir@ to the things to test for?
It shouldn't harm anything. Could you prepare a new patch?
Sure, please find it attached. I was also considering adding something under /var as well, but I didn't do that, because I think it will fall back to an "alsactl init" in that case (right?), so it still makes some sense to run alsactl without /var.
alsactl/90-alsa-restore.rules.in | 2 +- alsactl/Makefile.am | 1 + configure.ac | 1 + 3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/alsactl/90-alsa-restore.rules.in b/alsactl/90-alsa-restore.rules.in index c68119d..c83c6b5 100644 --- a/alsactl/90-alsa-restore.rules.in +++ b/alsactl/90-alsa-restore.rules.in @@ -1,4 +1,4 @@ -ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS!="card*", GOTO="alsa_restore_go" +ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS!="card*", TEST=="@datadir@", GOTO="alsa_restore_go" GOTO="alsa_restore_end"
LABEL="alsa_restore_go" diff --git a/alsactl/Makefile.am b/alsactl/Makefile.am index b862412..afbedb3 100644 --- a/alsactl/Makefile.am +++ b/alsactl/Makefile.am @@ -44,6 +44,7 @@ endif
edit = \ $(SED) -r -e 's,@sbindir@,$(sbindir),g' \
-e 's,@datadir\@,$(mydatadir),g' \diff --git a/configure.ac b/configure.ac index 7e6894a..a4d2db3 100644 --- a/configure.ac +++ b/configure.ac @@ -292,6 +292,7 @@ AC_DEFINE_UNQUOTED(SOUNDSDIR, "$soundsdir", [directory containing sample data])
mydatadir="$dir/alsa" AC_DEFINE_UNQUOTED(DATADIR, "$mydatadir", [directory containing alsa configuration]) +AC_SUBST(mydatadir)
AC_ARG_WITH(testsound, AS_HELP_STRING([--with-testsound=file], [give the path of test sound file for alsaconf]),
-- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
From 09a4abb5560448eb434a33fc237d578e14666940 Mon Sep 17 00:00:00 2001
From: David Henningsson david.henningsson@canonical.com Date: Fri, 13 Jun 2014 10:04:25 +0200 Subject: [PATCH] alsactl: Do not run udev rule before datadir/sbindir are both mounted
Sometimes 90-alsa-restore.rules is run before /usr is mounted, and alsactl restore depends on /usr/share/alsa being present.
If /usr/share/alsa is not present, we're so early in the boot process that alsa-restore.service (or upstart equivalent) will run later on.
BugLink: https://bugs.launchpad.net/bugs/1289730 Signed-off-by: David Henningsson david.henningsson@canonical.com
alsactl/90-alsa-restore.rules.in | 2 +- alsactl/Makefile.am | 1 + configure.ac | 1 + 3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/alsactl/90-alsa-restore.rules.in b/alsactl/90-alsa-restore.rules.in index c68119d..80fc043 100644 --- a/alsactl/90-alsa-restore.rules.in +++ b/alsactl/90-alsa-restore.rules.in @@ -1,4 +1,4 @@ -ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS!="card*", GOTO="alsa_restore_go" +ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS!="card*", TEST=="@sbindir@", TEST=="@datadir@", GOTO="alsa_restore_go" GOTO="alsa_restore_end"
IMO, it's better to use @mydatadir@ instead of @datadir@ here and...
LABEL="alsa_restore_go" diff --git a/alsactl/Makefile.am b/alsactl/Makefile.am index b862412..afbedb3 100644 --- a/alsactl/Makefile.am +++ b/alsactl/Makefile.am @@ -44,6 +44,7 @@ endif
edit = \ $(SED) -r -e 's,@sbindir@,$(sbindir),g' \
-e 's,@datadir\@,$(mydatadir),g' \
... here. Otherwise it may be confusing.
Other than that, the change looks good to me.
Jaroslav, could you fix up quickly in your side?
thanks,
Takashi
On 2014-06-13 11:20, Takashi Iwai wrote:
+++ b/alsactl/90-alsa-restore.rules.in @@ -1,4 +1,4 @@ -ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS!="card*", GOTO="alsa_restore_go" +ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS!="card*", TEST=="@sbindir@", TEST=="@datadir@", GOTO="alsa_restore_go" GOTO="alsa_restore_end"
IMO, it's better to use @mydatadir@ instead of @datadir@ here and...
Oops, sorry about that. Thanks for the review!
Attaching a fixup patch.
Hello all,
ALSA 1.0.28 packages are available for testing at
ftp://ftp.alsa-project.org/pub/testing/
Please, report any issues. I expect to announce the release on Monday.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project; Red Hat, Inc.
On 2014-06-13 12:08, Jaroslav Kysela wrote:
Hello all,
ALSA 1.0.28 packages are available for testing at
ftp://ftp.alsa-project.org/pub/testing/
Please, report any issues. I expect to announce the release on Monday.
Thanks!
I'm testing build of alsa-lib now and I have two questions:
1) the final so version seems to be libasound.so.2.0.0 for both 1.0.27 and 1.0.28. I'm not sure how important it is, but shouldn't this be increased to 2.0.1 or 2.1.0 to reflect code changes?
2) This probably is not a new issue, but I was wondering about all the extra files created in configure.ac, e g ctl_symbols_list.c. Are they ever cleaned by some "clean", "maintainerclean" or similar rule?
Date 13.6.2014 12:52, David Henningsson wrote:
On 2014-06-13 12:08, Jaroslav Kysela wrote:
Hello all,
ALSA 1.0.28 packages are available for testing at
ftp://ftp.alsa-project.org/pub/testing/
Please, report any issues. I expect to announce the release on Monday.
Thanks!
I'm testing build of alsa-lib now and I have two questions:
- the final so version seems to be libasound.so.2.0.0 for both 1.0.27
and 1.0.28. I'm not sure how important it is, but shouldn't this be increased to 2.0.1 or 2.1.0 to reflect code changes?
I think that we had some discussion about this and we use different system to identify new libraries:
1) there is snd_asoundlib_version() function 2) the packaging system identifies the exact used library version 3) we use deprecated linker warning for obsolete symbols 4) only "current" libtool version number will be changed when the library is not backwards compatible, otherwise all symbols must be present and compatible
Basically, we haven't found the current:revision:age numbering useable for our rules and as the libtool documentation states, it should not reflect the release number at all.
Even if the age is increased, nobody will have/known a correlation between the package release version and the library version. It means - we would update a number for nothing in this case.
Eventually (contradicting to the paragraphs above) the age might reflect the release number in form like:
1.0.28.3 -> 2:0:283
Future alsa-lib numbering:
2.33.5 -> 3:0:335 or 2:1:335 (if the library is backward compatible)
And this makes the question, if the version of packages should be increased to 2.0.0 in next release to lower the last number :-)
- This probably is not a new issue, but I was wondering about all the
extra files created in configure.ac, e g ctl_symbols_list.c. Are they ever cleaned by some "clean", "maintainerclean" or similar rule?
Nobody has required this. Patches are welcome. I'm using the 'git archive' to obtain the sources without these extra files for the packaging purposes and 'make dist'.
Jaroslav
13.06.2014 16:08, Jaroslav Kysela пишет:
Hello all,
ALSA 1.0.28 packages are available for testing at
ftp://ftp.alsa-project.org/pub/testing/
Please, report any issues. I expect to announce the release on Monday.
/usr/share/alsa/cards/Loopback.conf talks about "Intel HD audio (ICH6/ICH7)". This looks suspicious.
Date 13.6.2014 12:59, Alexander E. Patrakov wrote:
13.06.2014 16:08, Jaroslav Kysela пишет:
Hello all,
ALSA 1.0.28 packages are available for testing at
ftp://ftp.alsa-project.org/pub/testing/
Please, report any issues. I expect to announce the release on Monday.
/usr/share/alsa/cards/Loopback.conf talks about "Intel HD audio (ICH6/ICH7)". This looks suspicious.
Thanks. Fixed.
Jaroslav
While testing alsa-lib I found that the attached patch - which comes from Debian - probably should be applied upstream as well.
On 2014-06-13 12:08, Jaroslav Kysela wrote:
Hello all,
ALSA 1.0.28 packages are available for testing at
ftp://ftp.alsa-project.org/pub/testing/
Please, report any issues. I expect to announce the release on Monday.
Jaroslav
Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project; Red Hat, Inc.
Date 13.6.2014 13:02, David Henningsson wrote:
While testing alsa-lib I found that the attached patch - which comes from Debian - probably should be applied upstream as well.
Thanks. Applied.
Jaroslav
On 2014-06-13 12:08, Jaroslav Kysela wrote:
Hello all,
ALSA 1.0.28 packages are available for testing at
ftp://ftp.alsa-project.org/pub/testing/
Please, report any issues. I expect to announce the release on Monday.
Jaroslav
Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project; Red Hat, Inc.
Fri, 13 Jun 2014, Jaroslav Kysela wrote:
ALSA 1.0.28 packages are available for testing at
ftp://ftp.alsa-project.org/pub/testing/
Please, report any issues. I expect to announce the release on Monday.
I get "Assertion failed" with plug for float data. No patch yet. I'm still trying to understand how "plug" works. The bug was in earlier alsa versions too. Was almost fixed by 2da7b0c2 (discussion http://thread.gmane.org/gmane.linux.alsa.devel/119358)
I first found it with a complex ladspa upmix config, like: http://forums.gentoo.org/viewtopic-p-4528619.html#4528619 An easy way to see the assertion: pcm.!default { type plug slave.pcm { type null } ttable.0.0 1 } # aplay -fFLOAT_LE /dev/zero Playing raw data '/dev/zero' : Float 32 bit Little Endian, Rate 8000 Hz, Mono aplay: pcm_plug.c:388: snd_pcm_plug_change_channels: Assertion `snd_pcm_format_linear(slv->format)' failed. Aborted by signal Aborted...
participants (5)
-
Alexander E. Patrakov -
David Henningsson -
Jaroslav Kysela -
Sergey -
Takashi Iwai