[alsa-devel] additional problem
Hi gang! I've successfully been able to compile the alsa-utils package with the "--with-alsa-inc-prefix=/opt/staging/alsa/var/share/include --with-alsa-prefix=/opt/staging/alsa/lib", but the problem I'm having now is that the compiled binaries are looking for those directories during run-time and not just compile-time. Does anyone have any thoughts on using those directories for package creation, but that the software doesn't use the '/opt/staging/alsa' prefix during run-time?
Thanks, Dave
On 06/29/2011 09:57 AM, David Henderson wrote:
Hi gang! I've successfully been able to compile the alsa-utils package with the "--with-alsa-inc-prefix=/opt/staging/alsa/var/share/include --with-alsa-prefix=/opt/staging/alsa/lib", but the problem I'm having now is that the compiled binaries are looking for those directories during run-time and not just compile-time. Does anyone have any thoughts on using those directories for package creation, but that the software doesn't use the '/opt/staging/alsa' prefix during run-time?
Thanks, Dave
bump for help
On 06/30/2011 08:15 AM, David Henderson wrote:
On 06/29/2011 09:57 AM, David Henderson wrote:
Hi gang! I've successfully been able to compile the alsa-utils package with the "--with-alsa-inc-prefix=/opt/staging/alsa/var/share/include --with-alsa-prefix=/opt/staging/alsa/lib", but the problem I'm having now is that the compiled binaries are looking for those directories during run-time and not just compile-time. Does anyone have any thoughts on using those directories for package creation, but that the software doesn't use the '/opt/staging/alsa' prefix during run-time?
Thanks, Dave
bump for help
Maybe I'm asking the wrong questions :), so lets try this... what are the recommended steps to compile this software for package maintainers?
Thanks Dave
On Thu, Jun 30, 2011 at 11:43:46PM +0800, David Henderson wrote:
On 06/30/2011 08:15 AM, David Henderson wrote:
On 06/29/2011 09:57 AM, David Henderson wrote:
Hi gang! I've successfully been able to compile the alsa-utils package with the "--with-alsa-inc-prefix=/opt/staging/alsa/var/share/include --with-alsa-prefix=/opt/staging/alsa/lib", but the problem I'm having now is that the compiled binaries are looking for those directories during run-time and not just compile-time. Does anyone have any thoughts on using those directories for package creation, but that the software doesn't use the '/opt/staging/alsa' prefix during run-time?
Thanks, Dave
bump for help
Maybe I'm asking the wrong questions :), so lets try this... what are the recommended steps to compile this software for package maintainers?
I'm not the maintainer, so it might not be correct. They might use some kind of auto build services, e.g. build.opensuse.org
Thanks Dave _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
At Thu, 30 Jun 2011 08:15:41 -0400, David Henderson wrote:
On 06/29/2011 09:57 AM, David Henderson wrote:
Hi gang! I've successfully been able to compile the alsa-utils package with the "--with-alsa-inc-prefix=/opt/staging/alsa/var/share/include --with-alsa-prefix=/opt/staging/alsa/lib", but the problem I'm having now is that the compiled binaries are looking for those directories during run-time and not just compile-time. Does anyone have any thoughts on using those directories for package creation, but that the software doesn't use the '/opt/staging/alsa' prefix during run-time?
Thanks, Dave
bump for help
It works usually as is. Check once via ldd whether the binary is really linked with that fixed path. You may hit a problem when using libtool with *.la files, for example.
Takashi
On 07/01/2011 02:41 AM, Takashi Iwai wrote:
At Thu, 30 Jun 2011 08:15:41 -0400, David Henderson wrote:
On 06/29/2011 09:57 AM, David Henderson wrote:
Hi gang! I've successfully been able to compile the alsa-utils package with the "--with-alsa-inc-prefix=/opt/staging/alsa/var/share/include --with-alsa-prefix=/opt/staging/alsa/lib", but the problem I'm having now is that the compiled binaries are looking for those directories during run-time and not just compile-time. Does anyone have any thoughts on using those directories for package creation, but that the software doesn't use the '/opt/staging/alsa' prefix during run-time?
Thanks, Dave
bump for help
It works usually as is. Check once via ldd whether the binary is really linked with that fixed path. You may hit a problem when using libtool with *.la files, for example.
Takashi
Thanks for the continued help Takashi. I've performed the requested steps, but all referenced libs are correct (e.g. /lib/... and not /opt/staging/alsa/lib/...). Any other thoughts?
Thanks, Dave
At Mon, 11 Jul 2011 10:26:05 -0400, David Henderson wrote:
On 07/01/2011 02:41 AM, Takashi Iwai wrote:
At Thu, 30 Jun 2011 08:15:41 -0400, David Henderson wrote:
On 06/29/2011 09:57 AM, David Henderson wrote:
Hi gang! I've successfully been able to compile the alsa-utils package with the "--with-alsa-inc-prefix=/opt/staging/alsa/var/share/include --with-alsa-prefix=/opt/staging/alsa/lib", but the problem I'm having now is that the compiled binaries are looking for those directories during run-time and not just compile-time. Does anyone have any thoughts on using those directories for package creation, but that the software doesn't use the '/opt/staging/alsa' prefix during run-time?
Thanks, Dave
bump for help
It works usually as is. Check once via ldd whether the binary is really linked with that fixed path. You may hit a problem when using libtool with *.la files, for example.
Takashi
Thanks for the continued help Takashi. I've performed the requested steps, but all referenced libs are correct (e.g. /lib/... and not /opt/staging/alsa/lib/...). Any other thoughts?
Check ldd output of the binary. If it contains the /opt/ path, it means that the path is set statically into the binary. The old libtool had a related problem, IIRC.
Other than that, rather ask your distro. It's really distro-specific.
Takashi
On 07/11/2011 10:43 AM, Takashi Iwai wrote:
At Mon, 11 Jul 2011 10:26:05 -0400, David Henderson wrote:
On 07/01/2011 02:41 AM, Takashi Iwai wrote:
At Thu, 30 Jun 2011 08:15:41 -0400, David Henderson wrote:
On 06/29/2011 09:57 AM, David Henderson wrote:
Hi gang! I've successfully been able to compile the alsa-utils package with the "--with-alsa-inc-prefix=/opt/staging/alsa/var/share/include --with-alsa-prefix=/opt/staging/alsa/lib", but the problem I'm having now is that the compiled binaries are looking for those directories during run-time and not just compile-time. Does anyone have any thoughts on using those directories for package creation, but that the software doesn't use the '/opt/staging/alsa' prefix during run-time?
Thanks, Dave
bump for help
It works usually as is. Check once via ldd whether the binary is really linked with that fixed path. You may hit a problem when using libtool with *.la files, for example.
Takashi
Thanks for the continued help Takashi. I've performed the requested steps, but all referenced libs are correct (e.g. /lib/... and not /opt/staging/alsa/lib/...). Any other thoughts?
Check ldd output of the binary. If it contains the /opt/ path, it means that the path is set statically into the binary. The old libtool had a related problem, IIRC.
Other than that, rather ask your distro. It's really distro-specific.
Takashi
Hey Takashi, I performed the requested steps, but the output is still correct (e.g. /lib/... and not /opt/staging/alsa/lib/...). As stated in the reply to Alex, the only place that path (from the error message) is used during the compile process is during the 'make' call using DESTDIR. Other than that, the paths are root based and don't use the /opt/staging/alsa prefix. Other thoughts?
Dave
At Mon, 11 Jul 2011 11:05:11 -0400, David Henderson wrote:
On 07/11/2011 10:43 AM, Takashi Iwai wrote:
At Mon, 11 Jul 2011 10:26:05 -0400, David Henderson wrote:
On 07/01/2011 02:41 AM, Takashi Iwai wrote:
At Thu, 30 Jun 2011 08:15:41 -0400, David Henderson wrote:
On 06/29/2011 09:57 AM, David Henderson wrote:
Hi gang! I've successfully been able to compile the alsa-utils package with the "--with-alsa-inc-prefix=/opt/staging/alsa/var/share/include --with-alsa-prefix=/opt/staging/alsa/lib", but the problem I'm having now is that the compiled binaries are looking for those directories during run-time and not just compile-time. Does anyone have any thoughts on using those directories for package creation, but that the software doesn't use the '/opt/staging/alsa' prefix during run-time?
Thanks, Dave
bump for help
It works usually as is. Check once via ldd whether the binary is really linked with that fixed path. You may hit a problem when using libtool with *.la files, for example.
Takashi
Thanks for the continued help Takashi. I've performed the requested steps, but all referenced libs are correct (e.g. /lib/... and not /opt/staging/alsa/lib/...). Any other thoughts?
Check ldd output of the binary. If it contains the /opt/ path, it means that the path is set statically into the binary. The old libtool had a related problem, IIRC.
Other than that, rather ask your distro. It's really distro-specific.
Takashi
Hey Takashi, I performed the requested steps, but the output is still correct (e.g. /lib/... and not /opt/staging/alsa/lib/...).
So, what shows ldd at all? Too little information.
Takashi
On 07/11/2011 11:12 AM, Takashi Iwai wrote:
At Mon, 11 Jul 2011 11:05:11 -0400, David Henderson wrote:
On 07/11/2011 10:43 AM, Takashi Iwai wrote:
At Mon, 11 Jul 2011 10:26:05 -0400, David Henderson wrote:
On 07/01/2011 02:41 AM, Takashi Iwai wrote:
At Thu, 30 Jun 2011 08:15:41 -0400, David Henderson wrote:
On 06/29/2011 09:57 AM, David Henderson wrote: > Hi gang! I've successfully been able to compile the alsa-utils > package with the > "--with-alsa-inc-prefix=/opt/staging/alsa/var/share/include > --with-alsa-prefix=/opt/staging/alsa/lib", but the problem I'm having > now is that the compiled binaries are looking for those directories > during run-time and not just compile-time. Does anyone have any > thoughts on using those directories for package creation, but that the > software doesn't use the '/opt/staging/alsa' prefix during run-time? > > Thanks, > Dave bump for help
It works usually as is. Check once via ldd whether the binary is really linked with that fixed path. You may hit a problem when using libtool with *.la files, for example.
Takashi
Thanks for the continued help Takashi. I've performed the requested steps, but all referenced libs are correct (e.g. /lib/... and not /opt/staging/alsa/lib/...). Any other thoughts?
Check ldd output of the binary. If it contains the /opt/ path, it means that the path is set statically into the binary. The old libtool had a related problem, IIRC.
Other than that, rather ask your distro. It's really distro-specific.
Takashi
Hey Takashi, I performed the requested steps, but the output is still correct (e.g. /lib/... and not /opt/staging/alsa/lib/...).
So, what shows ldd at all? Too little information.
Takashi
# ldd /bin/amixer linux-gate.so.1 => (0xb7768000) libm.so.6 => /lib/libm.so.6 (0xb7741000) libasound.so.2 => /lib/libasound.so.2 (0xb7667000) libdl.so.2 => /lib/libdl.so.2 (0xb7663000) libpthread.so.0 => /lib/libpthread.so.0 (0xb764b000) libc.so.6 => /lib/libc.so.6 (0xb7507000) /lib/ld-linux.so.2 (0xb7769000) librt.so.1 => /lib/librt.so.1 (0xb74fe000)
Dave
At Mon, 11 Jul 2011 11:13:03 -0400, David Henderson wrote:
On 07/11/2011 11:12 AM, Takashi Iwai wrote:
At Mon, 11 Jul 2011 11:05:11 -0400, David Henderson wrote:
On 07/11/2011 10:43 AM, Takashi Iwai wrote:
At Mon, 11 Jul 2011 10:26:05 -0400, David Henderson wrote:
On 07/01/2011 02:41 AM, Takashi Iwai wrote:
At Thu, 30 Jun 2011 08:15:41 -0400, David Henderson wrote: > On 06/29/2011 09:57 AM, David Henderson wrote: >> Hi gang! I've successfully been able to compile the alsa-utils >> package with the >> "--with-alsa-inc-prefix=/opt/staging/alsa/var/share/include >> --with-alsa-prefix=/opt/staging/alsa/lib", but the problem I'm having >> now is that the compiled binaries are looking for those directories >> during run-time and not just compile-time. Does anyone have any >> thoughts on using those directories for package creation, but that the >> software doesn't use the '/opt/staging/alsa' prefix during run-time? >> >> Thanks, >> Dave > bump for help It works usually as is. Check once via ldd whether the binary is really linked with that fixed path. You may hit a problem when using libtool with *.la files, for example.
Takashi
Thanks for the continued help Takashi. I've performed the requested steps, but all referenced libs are correct (e.g. /lib/... and not /opt/staging/alsa/lib/...). Any other thoughts?
Check ldd output of the binary. If it contains the /opt/ path, it means that the path is set statically into the binary. The old libtool had a related problem, IIRC.
Other than that, rather ask your distro. It's really distro-specific.
Takashi
Hey Takashi, I performed the requested steps, but the output is still correct (e.g. /lib/... and not /opt/staging/alsa/lib/...).
So, what shows ldd at all? Too little information.
Takashi
# ldd /bin/amixer linux-gate.so.1 => (0xb7768000) libm.so.6 => /lib/libm.so.6 (0xb7741000) libasound.so.2 => /lib/libasound.so.2 (0xb7667000) libdl.so.2 => /lib/libdl.so.2 (0xb7663000) libpthread.so.0 => /lib/libpthread.so.0 (0xb764b000) libc.so.6 => /lib/libc.so.6 (0xb7507000) /lib/ld-linux.so.2 (0xb7769000) librt.so.1 => /lib/librt.so.1 (0xb74fe000)
Then what happens if you run /bin/amixer ?
Takashi
On 07/11/2011 11:17 AM, Takashi Iwai wrote:
At Mon, 11 Jul 2011 11:13:03 -0400, David Henderson wrote:
On 07/11/2011 11:12 AM, Takashi Iwai wrote:
At Mon, 11 Jul 2011 11:05:11 -0400, David Henderson wrote:
On 07/11/2011 10:43 AM, Takashi Iwai wrote:
At Mon, 11 Jul 2011 10:26:05 -0400, David Henderson wrote:
On 07/01/2011 02:41 AM, Takashi Iwai wrote: > At Thu, 30 Jun 2011 08:15:41 -0400, > David Henderson wrote: >> On 06/29/2011 09:57 AM, David Henderson wrote: >>> Hi gang! I've successfully been able to compile the alsa-utils >>> package with the >>> "--with-alsa-inc-prefix=/opt/staging/alsa/var/share/include >>> --with-alsa-prefix=/opt/staging/alsa/lib", but the problem I'm having >>> now is that the compiled binaries are looking for those directories >>> during run-time and not just compile-time. Does anyone have any >>> thoughts on using those directories for package creation, but that the >>> software doesn't use the '/opt/staging/alsa' prefix during run-time? >>> >>> Thanks, >>> Dave >> bump for help > It works usually as is. Check once via ldd whether the binary is > really linked with that fixed path. You may hit a problem when using > libtool with *.la files, for example. > > > Takashi Thanks for the continued help Takashi. I've performed the requested steps, but all referenced libs are correct (e.g. /lib/... and not /opt/staging/alsa/lib/...). Any other thoughts?
Check ldd output of the binary. If it contains the /opt/ path, it means that the path is set statically into the binary. The old libtool had a related problem, IIRC.
Other than that, rather ask your distro. It's really distro-specific.
Takashi
Hey Takashi, I performed the requested steps, but the output is still correct (e.g. /lib/... and not /opt/staging/alsa/lib/...).
So, what shows ldd at all? Too little information.
Takashi
# ldd /bin/amixer linux-gate.so.1 => (0xb7768000) libm.so.6 => /lib/libm.so.6 (0xb7741000) libasound.so.2 => /lib/libasound.so.2 (0xb7667000) libdl.so.2 => /lib/libdl.so.2 (0xb7663000) libpthread.so.0 => /lib/libpthread.so.0 (0xb764b000) libc.so.6 => /lib/libc.so.6 (0xb7507000) /lib/ld-linux.so.2 (0xb7769000) librt.so.1 => /lib/librt.so.1 (0xb74fe000)
Then what happens if you run /bin/amixer ?
Takashi
# /bin/amixer ALSA lib conf.c:3601:(snd_config_update_r) Cannot access file /opt/staging/package/var/share/alsa/alsa.conf ALSA lib control.c:902:(snd_ctl_open_noupdate) Invalid CTL default amixer: Mixer attach default error: No such file or directory
Dave
At Mon, 11 Jul 2011 11:25:34 -0400, David Henderson wrote:
On 07/11/2011 11:17 AM, Takashi Iwai wrote:
At Mon, 11 Jul 2011 11:13:03 -0400, David Henderson wrote:
On 07/11/2011 11:12 AM, Takashi Iwai wrote:
At Mon, 11 Jul 2011 11:05:11 -0400, David Henderson wrote:
On 07/11/2011 10:43 AM, Takashi Iwai wrote:
At Mon, 11 Jul 2011 10:26:05 -0400, David Henderson wrote: > On 07/01/2011 02:41 AM, Takashi Iwai wrote: >> At Thu, 30 Jun 2011 08:15:41 -0400, >> David Henderson wrote: >>> On 06/29/2011 09:57 AM, David Henderson wrote: >>>> Hi gang! I've successfully been able to compile the alsa-utils >>>> package with the >>>> "--with-alsa-inc-prefix=/opt/staging/alsa/var/share/include >>>> --with-alsa-prefix=/opt/staging/alsa/lib", but the problem I'm having >>>> now is that the compiled binaries are looking for those directories >>>> during run-time and not just compile-time. Does anyone have any >>>> thoughts on using those directories for package creation, but that the >>>> software doesn't use the '/opt/staging/alsa' prefix during run-time? >>>> >>>> Thanks, >>>> Dave >>> bump for help >> It works usually as is. Check once via ldd whether the binary is >> really linked with that fixed path. You may hit a problem when using >> libtool with *.la files, for example. >> >> >> Takashi > Thanks for the continued help Takashi. I've performed the requested > steps, but all referenced libs are correct (e.g. /lib/... and not > /opt/staging/alsa/lib/...). Any other thoughts? Check ldd output of the binary. If it contains the /opt/ path, it means that the path is set statically into the binary. The old libtool had a related problem, IIRC.
Other than that, rather ask your distro. It's really distro-specific.
Takashi
Hey Takashi, I performed the requested steps, but the output is still correct (e.g. /lib/... and not /opt/staging/alsa/lib/...).
So, what shows ldd at all? Too little information.
Takashi
# ldd /bin/amixer linux-gate.so.1 => (0xb7768000) libm.so.6 => /lib/libm.so.6 (0xb7741000) libasound.so.2 => /lib/libasound.so.2 (0xb7667000) libdl.so.2 => /lib/libdl.so.2 (0xb7663000) libpthread.so.0 => /lib/libpthread.so.0 (0xb764b000) libc.so.6 => /lib/libc.so.6 (0xb7507000) /lib/ld-linux.so.2 (0xb7769000) librt.so.1 => /lib/librt.so.1 (0xb74fe000)
Then what happens if you run /bin/amixer ?
Takashi
# /bin/amixer ALSA lib conf.c:3601:(snd_config_update_r) Cannot access file /opt/staging/package/var/share/alsa/alsa.conf ALSA lib control.c:902:(snd_ctl_open_noupdate) Invalid CTL default amixer: Mixer attach default error: No such file or directory
It's a problem of alsa-lib build, not alsa-utils. Maybe you changed --prefix wrongly at alsa-lib build time?
Takashi
On 07/11/2011 11:52 AM, Takashi Iwai wrote:
At Mon, 11 Jul 2011 11:25:34 -0400, David Henderson wrote:
On 07/11/2011 11:17 AM, Takashi Iwai wrote:
At Mon, 11 Jul 2011 11:13:03 -0400, David Henderson wrote:
On 07/11/2011 11:12 AM, Takashi Iwai wrote:
At Mon, 11 Jul 2011 11:05:11 -0400, David Henderson wrote:
On 07/11/2011 10:43 AM, Takashi Iwai wrote: > At Mon, 11 Jul 2011 10:26:05 -0400, > David Henderson wrote: >> On 07/01/2011 02:41 AM, Takashi Iwai wrote: >>> At Thu, 30 Jun 2011 08:15:41 -0400, >>> David Henderson wrote: >>>> On 06/29/2011 09:57 AM, David Henderson wrote: >>>>> Hi gang! I've successfully been able to compile the alsa-utils >>>>> package with the >>>>> "--with-alsa-inc-prefix=/opt/staging/alsa/var/share/include >>>>> --with-alsa-prefix=/opt/staging/alsa/lib", but the problem I'm having >>>>> now is that the compiled binaries are looking for those directories >>>>> during run-time and not just compile-time. Does anyone have any >>>>> thoughts on using those directories for package creation, but that the >>>>> software doesn't use the '/opt/staging/alsa' prefix during run-time? >>>>> >>>>> Thanks, >>>>> Dave >>>> bump for help >>> It works usually as is. Check once via ldd whether the binary is >>> really linked with that fixed path. You may hit a problem when using >>> libtool with *.la files, for example. >>> >>> >>> Takashi >> Thanks for the continued help Takashi. I've performed the requested >> steps, but all referenced libs are correct (e.g. /lib/... and not >> /opt/staging/alsa/lib/...). Any other thoughts? > Check ldd output of the binary. If it contains the /opt/ path, it > means that the path is set statically into the binary. The old > libtool had a related problem, IIRC. > > Other than that, rather ask your distro. It's really distro-specific. > > > Takashi Hey Takashi, I performed the requested steps, but the output is still correct (e.g. /lib/... and not /opt/staging/alsa/lib/...).
So, what shows ldd at all? Too little information.
Takashi
# ldd /bin/amixer linux-gate.so.1 => (0xb7768000) libm.so.6 => /lib/libm.so.6 (0xb7741000) libasound.so.2 => /lib/libasound.so.2 (0xb7667000) libdl.so.2 => /lib/libdl.so.2 (0xb7663000) libpthread.so.0 => /lib/libpthread.so.0 (0xb764b000) libc.so.6 => /lib/libc.so.6 (0xb7507000) /lib/ld-linux.so.2 (0xb7769000) librt.so.1 => /lib/librt.so.1 (0xb74fe000)
Then what happens if you run /bin/amixer ?
Takashi
# /bin/amixer ALSA lib conf.c:3601:(snd_config_update_r) Cannot access file /opt/staging/package/var/share/alsa/alsa.conf ALSA lib control.c:902:(snd_ctl_open_noupdate) Invalid CTL default amixer: Mixer attach default error: No such file or directory
It's a problem of alsa-lib build, not alsa-utils. Maybe you changed --prefix wrongly at alsa-lib build time?
Takashi
That solved the problem! Thanks Takashi! Now that I've gotten the software to compile correctly and I'm able to interact with the audio hardware using alsamixer, I tried to run the speaker-test and now I'm getting the error "ALSA lib pcm_direct.c:1616:(snd1_pcm_direct_parse_open_conf) The field ipc_gid must be a valid group (create group audio)" which I can see is a problem with the absence of the 'audio' group on the distro. Is there a way I can configure alsa to use a different group other than 'audio'?
Thanks, Dave
At Tue, 12 Jul 2011 09:05:31 -0400, David Henderson wrote:
On 07/11/2011 11:52 AM, Takashi Iwai wrote:
At Mon, 11 Jul 2011 11:25:34 -0400, David Henderson wrote:
On 07/11/2011 11:17 AM, Takashi Iwai wrote:
At Mon, 11 Jul 2011 11:13:03 -0400, David Henderson wrote:
On 07/11/2011 11:12 AM, Takashi Iwai wrote:
At Mon, 11 Jul 2011 11:05:11 -0400, David Henderson wrote: > On 07/11/2011 10:43 AM, Takashi Iwai wrote: >> At Mon, 11 Jul 2011 10:26:05 -0400, >> David Henderson wrote: >>> On 07/01/2011 02:41 AM, Takashi Iwai wrote: >>>> At Thu, 30 Jun 2011 08:15:41 -0400, >>>> David Henderson wrote: >>>>> On 06/29/2011 09:57 AM, David Henderson wrote: >>>>>> Hi gang! I've successfully been able to compile the alsa-utils >>>>>> package with the >>>>>> "--with-alsa-inc-prefix=/opt/staging/alsa/var/share/include >>>>>> --with-alsa-prefix=/opt/staging/alsa/lib", but the problem I'm having >>>>>> now is that the compiled binaries are looking for those directories >>>>>> during run-time and not just compile-time. Does anyone have any >>>>>> thoughts on using those directories for package creation, but that the >>>>>> software doesn't use the '/opt/staging/alsa' prefix during run-time? >>>>>> >>>>>> Thanks, >>>>>> Dave >>>>> bump for help >>>> It works usually as is. Check once via ldd whether the binary is >>>> really linked with that fixed path. You may hit a problem when using >>>> libtool with *.la files, for example. >>>> >>>> >>>> Takashi >>> Thanks for the continued help Takashi. I've performed the requested >>> steps, but all referenced libs are correct (e.g. /lib/... and not >>> /opt/staging/alsa/lib/...). Any other thoughts? >> Check ldd output of the binary. If it contains the /opt/ path, it >> means that the path is set statically into the binary. The old >> libtool had a related problem, IIRC. >> >> Other than that, rather ask your distro. It's really distro-specific. >> >> >> Takashi > Hey Takashi, I performed the requested steps, but the output is still > correct (e.g. /lib/... and not /opt/staging/alsa/lib/...). So, what shows ldd at all? Too little information.
Takashi
# ldd /bin/amixer linux-gate.so.1 => (0xb7768000) libm.so.6 => /lib/libm.so.6 (0xb7741000) libasound.so.2 => /lib/libasound.so.2 (0xb7667000) libdl.so.2 => /lib/libdl.so.2 (0xb7663000) libpthread.so.0 => /lib/libpthread.so.0 (0xb764b000) libc.so.6 => /lib/libc.so.6 (0xb7507000) /lib/ld-linux.so.2 (0xb7769000) librt.so.1 => /lib/librt.so.1 (0xb74fe000)
Then what happens if you run /bin/amixer ?
Takashi
# /bin/amixer ALSA lib conf.c:3601:(snd_config_update_r) Cannot access file /opt/staging/package/var/share/alsa/alsa.conf ALSA lib control.c:902:(snd_ctl_open_noupdate) Invalid CTL default amixer: Mixer attach default error: No such file or directory
It's a problem of alsa-lib build, not alsa-utils. Maybe you changed --prefix wrongly at alsa-lib build time?
Takashi
That solved the problem! Thanks Takashi! Now that I've gotten the software to compile correctly and I'm able to interact with the audio hardware using alsamixer, I tried to run the speaker-test and now I'm getting the error "ALSA lib pcm_direct.c:1616:(snd1_pcm_direct_parse_open_conf) The field ipc_gid must be a valid group (create group audio)" which I can see is a problem with the absence of the 'audio' group on the distro. Is there a way I can configure alsa to use a different group other than 'audio'?
You can set defaults.pcm.ipc_gid in ~/.asoundrc or /etc/asound.conf. Put a line like defaults.pcm.ipc_gid "user"
then the group "user" will be used for dmix/dsnoop.
Takashi
On 07/12/2011 09:13 AM, Takashi Iwai wrote:
At Tue, 12 Jul 2011 09:05:31 -0400, David Henderson wrote:
On 07/11/2011 11:52 AM, Takashi Iwai wrote:
At Mon, 11 Jul 2011 11:25:34 -0400, David Henderson wrote:
On 07/11/2011 11:17 AM, Takashi Iwai wrote:
At Mon, 11 Jul 2011 11:13:03 -0400, David Henderson wrote:
On 07/11/2011 11:12 AM, Takashi Iwai wrote: > At Mon, 11 Jul 2011 11:05:11 -0400, > David Henderson wrote: >> On 07/11/2011 10:43 AM, Takashi Iwai wrote: >>> At Mon, 11 Jul 2011 10:26:05 -0400, >>> David Henderson wrote: >>>> On 07/01/2011 02:41 AM, Takashi Iwai wrote: >>>>> At Thu, 30 Jun 2011 08:15:41 -0400, >>>>> David Henderson wrote: >>>>>> On 06/29/2011 09:57 AM, David Henderson wrote: >>>>>>> Hi gang! I've successfully been able to compile the alsa-utils >>>>>>> package with the >>>>>>> "--with-alsa-inc-prefix=/opt/staging/alsa/var/share/include >>>>>>> --with-alsa-prefix=/opt/staging/alsa/lib", but the problem I'm having >>>>>>> now is that the compiled binaries are looking for those directories >>>>>>> during run-time and not just compile-time. Does anyone have any >>>>>>> thoughts on using those directories for package creation, but that the >>>>>>> software doesn't use the '/opt/staging/alsa' prefix during run-time? >>>>>>> >>>>>>> Thanks, >>>>>>> Dave >>>>>> bump for help >>>>> It works usually as is. Check once via ldd whether the binary is >>>>> really linked with that fixed path. You may hit a problem when using >>>>> libtool with *.la files, for example. >>>>> >>>>> >>>>> Takashi >>>> Thanks for the continued help Takashi. I've performed the requested >>>> steps, but all referenced libs are correct (e.g. /lib/... and not >>>> /opt/staging/alsa/lib/...). Any other thoughts? >>> Check ldd output of the binary. If it contains the /opt/ path, it >>> means that the path is set statically into the binary. The old >>> libtool had a related problem, IIRC. >>> >>> Other than that, rather ask your distro. It's really distro-specific. >>> >>> >>> Takashi >> Hey Takashi, I performed the requested steps, but the output is still >> correct (e.g. /lib/... and not /opt/staging/alsa/lib/...). > So, what shows ldd at all? Too little information. > > > Takashi # ldd /bin/amixer linux-gate.so.1 => (0xb7768000) libm.so.6 => /lib/libm.so.6 (0xb7741000) libasound.so.2 => /lib/libasound.so.2 (0xb7667000) libdl.so.2 => /lib/libdl.so.2 (0xb7663000) libpthread.so.0 => /lib/libpthread.so.0 (0xb764b000) libc.so.6 => /lib/libc.so.6 (0xb7507000) /lib/ld-linux.so.2 (0xb7769000) librt.so.1 => /lib/librt.so.1 (0xb74fe000)
Then what happens if you run /bin/amixer ?
Takashi
# /bin/amixer ALSA lib conf.c:3601:(snd_config_update_r) Cannot access file /opt/staging/package/var/share/alsa/alsa.conf ALSA lib control.c:902:(snd_ctl_open_noupdate) Invalid CTL default amixer: Mixer attach default error: No such file or directory
It's a problem of alsa-lib build, not alsa-utils. Maybe you changed --prefix wrongly at alsa-lib build time?
Takashi
That solved the problem! Thanks Takashi! Now that I've gotten the software to compile correctly and I'm able to interact with the audio hardware using alsamixer, I tried to run the speaker-test and now I'm getting the error "ALSA lib pcm_direct.c:1616:(snd1_pcm_direct_parse_open_conf) The field ipc_gid must be a valid group (create group audio)" which I can see is a problem with the absence of the 'audio' group on the distro. Is there a way I can configure alsa to use a different group other than 'audio'?
You can set defaults.pcm.ipc_gid in ~/.asoundrc or /etc/asound.conf. Put a line like defaults.pcm.ipc_gid "user"
then the group "user" will be used for dmix/dsnoop.
Takashi
Thanks again for the help Takashi. Ok, I've created the /etc/asound.conf file with the appropriate group and now I'm trying to run the aplay binary and I'm not getting any error messages, but I'm also not hearing any sounds from the speakers.
# aplay freq10-30000-10s.wav Playing WAVE 'freq10-30000-10s.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Mono
# speaker-test -w ./freq10-30000-10s.wav
speaker-test 1.0.23
Playback device is default Stream parameters are 48000Hz, S16_LE, 1 channels Using 16 octaves of pink noise Rate set to 48000Hz (requested 48000Hz) Buffer size range from 2048 to 8192 Period size range from 1024 to 1024 Using max buffer size 8192 Periods = 4 was set period_size = 1024 was set buffer_size = 8192 0 - Front Left Time per period = 2.835792 0 - Front Left Time per period = 2.986653 0 - Front Left Time per period = 2.986654 0 - Front Left ...snip...
I've made sure nothing is muted with the audio hardware by using alsamixer and changed the permissions on the files within the /etc/snd directory. Any other thoughts?
Dave
On 07/12/2011 09:30 AM, David Henderson wrote:
On 07/12/2011 09:13 AM, Takashi Iwai wrote:
At Tue, 12 Jul 2011 09:05:31 -0400, David Henderson wrote:
On 07/11/2011 11:52 AM, Takashi Iwai wrote:
At Mon, 11 Jul 2011 11:25:34 -0400, David Henderson wrote:
On 07/11/2011 11:17 AM, Takashi Iwai wrote:
At Mon, 11 Jul 2011 11:13:03 -0400, David Henderson wrote: > On 07/11/2011 11:12 AM, Takashi Iwai wrote: >> At Mon, 11 Jul 2011 11:05:11 -0400, >> David Henderson wrote: >>> On 07/11/2011 10:43 AM, Takashi Iwai wrote: >>>> At Mon, 11 Jul 2011 10:26:05 -0400, >>>> David Henderson wrote: >>>>> On 07/01/2011 02:41 AM, Takashi Iwai wrote: >>>>>> At Thu, 30 Jun 2011 08:15:41 -0400, >>>>>> David Henderson wrote: >>>>>>> On 06/29/2011 09:57 AM, David Henderson wrote: >>>>>>>> Hi gang! I've successfully been able to compile the >>>>>>>> alsa-utils >>>>>>>> package with the >>>>>>>> "--with-alsa-inc-prefix=/opt/staging/alsa/var/share/include >>>>>>>> --with-alsa-prefix=/opt/staging/alsa/lib", but the >>>>>>>> problem I'm having >>>>>>>> now is that the compiled binaries are looking for those >>>>>>>> directories >>>>>>>> during run-time and not just compile-time. Does anyone >>>>>>>> have any >>>>>>>> thoughts on using those directories for package creation, >>>>>>>> but that the >>>>>>>> software doesn't use the '/opt/staging/alsa' prefix >>>>>>>> during run-time? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Dave >>>>>>> bump for help >>>>>> It works usually as is. Check once via ldd whether the >>>>>> binary is >>>>>> really linked with that fixed path. You may hit a problem >>>>>> when using >>>>>> libtool with *.la files, for example. >>>>>> >>>>>> >>>>>> Takashi >>>>> Thanks for the continued help Takashi. I've performed the >>>>> requested >>>>> steps, but all referenced libs are correct (e.g. /lib/... >>>>> and not >>>>> /opt/staging/alsa/lib/...). Any other thoughts? >>>> Check ldd output of the binary. If it contains the /opt/ >>>> path, it >>>> means that the path is set statically into the binary. The old >>>> libtool had a related problem, IIRC. >>>> >>>> Other than that, rather ask your distro. It's really >>>> distro-specific. >>>> >>>> >>>> Takashi >>> Hey Takashi, I performed the requested steps, but the output >>> is still >>> correct (e.g. /lib/... and not /opt/staging/alsa/lib/...). >> So, what shows ldd at all? Too little information. >> >> >> Takashi > # ldd /bin/amixer > linux-gate.so.1 => (0xb7768000) > libm.so.6 => /lib/libm.so.6 (0xb7741000) > libasound.so.2 => /lib/libasound.so.2 (0xb7667000) > libdl.so.2 => /lib/libdl.so.2 (0xb7663000) > libpthread.so.0 => /lib/libpthread.so.0 (0xb764b000) > libc.so.6 => /lib/libc.so.6 (0xb7507000) > /lib/ld-linux.so.2 (0xb7769000) > librt.so.1 => /lib/librt.so.1 (0xb74fe000) Then what happens if you run /bin/amixer ?
Takashi
# /bin/amixer ALSA lib conf.c:3601:(snd_config_update_r) Cannot access file /opt/staging/package/var/share/alsa/alsa.conf ALSA lib control.c:902:(snd_ctl_open_noupdate) Invalid CTL default amixer: Mixer attach default error: No such file or directory
It's a problem of alsa-lib build, not alsa-utils. Maybe you changed --prefix wrongly at alsa-lib build time?
Takashi
That solved the problem! Thanks Takashi! Now that I've gotten the software to compile correctly and I'm able to interact with the audio hardware using alsamixer, I tried to run the speaker-test and now I'm getting the error "ALSA lib pcm_direct.c:1616:(snd1_pcm_direct_parse_open_conf) The field ipc_gid must be a valid group (create group audio)" which I can see is a problem with the absence of the 'audio' group on the distro. Is there a way I can configure alsa to use a different group other than 'audio'?
You can set defaults.pcm.ipc_gid in ~/.asoundrc or /etc/asound.conf. Put a line like defaults.pcm.ipc_gid "user"
then the group "user" will be used for dmix/dsnoop.
Takashi
Thanks again for the help Takashi. Ok, I've created the /etc/asound.conf file with the appropriate group and now I'm trying to run the aplay binary and I'm not getting any error messages, but I'm also not hearing any sounds from the speakers.
# aplay freq10-30000-10s.wav Playing WAVE 'freq10-30000-10s.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Mono
# speaker-test -w ./freq10-30000-10s.wav
speaker-test 1.0.23
Playback device is default Stream parameters are 48000Hz, S16_LE, 1 channels Using 16 octaves of pink noise Rate set to 48000Hz (requested 48000Hz) Buffer size range from 2048 to 8192 Period size range from 1024 to 1024 Using max buffer size 8192 Periods = 4 was set period_size = 1024 was set buffer_size = 8192 0 - Front Left Time per period = 2.835792 0 - Front Left Time per period = 2.986653 0 - Front Left Time per period = 2.986654 0 - Front Left ...snip...
I've made sure nothing is muted with the audio hardware by using alsamixer and changed the permissions on the files within the /etc/snd directory. Any other thoughts?
Dave
bump for help
At Wed, 13 Jul 2011 09:14:55 -0400, David Henderson wrote:
Thanks again for the help Takashi. Ok, I've created the /etc/asound.conf file with the appropriate group and now I'm trying to run the aplay binary and I'm not getting any error messages, but I'm also not hearing any sounds from the speakers.
# aplay freq10-30000-10s.wav Playing WAVE 'freq10-30000-10s.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Mono
# speaker-test -w ./freq10-30000-10s.wav
speaker-test 1.0.23
Playback device is default Stream parameters are 48000Hz, S16_LE, 1 channels Using 16 octaves of pink noise Rate set to 48000Hz (requested 48000Hz) Buffer size range from 2048 to 8192 Period size range from 1024 to 1024 Using max buffer size 8192 Periods = 4 was set period_size = 1024 was set buffer_size = 8192 0 - Front Left Time per period = 2.835792 0 - Front Left Time per period = 2.986653 0 - Front Left Time per period = 2.986654 0 - Front Left ...snip...
I've made sure nothing is muted with the audio hardware by using alsamixer and changed the permissions on the files within the /etc/snd directory. Any other thoughts?
Dave
bump for help
You didn't give any useful information about the hardware itself, so no one can answer. Did it ever sound correctly with any other distro at all?
Please don't mix up the custom-build problem and the driver problem. The problem with silent output is more likely a driver issue (or a configuration issue).
Takashi
On 07/13/2011 10:08 AM, Takashi Iwai wrote:
At Wed, 13 Jul 2011 09:14:55 -0400, David Henderson wrote:
Thanks again for the help Takashi. Ok, I've created the /etc/asound.conf file with the appropriate group and now I'm trying to run the aplay binary and I'm not getting any error messages, but I'm also not hearing any sounds from the speakers.
# aplay freq10-30000-10s.wav Playing WAVE 'freq10-30000-10s.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Mono
# speaker-test -w ./freq10-30000-10s.wav
speaker-test 1.0.23
Playback device is default Stream parameters are 48000Hz, S16_LE, 1 channels Using 16 octaves of pink noise Rate set to 48000Hz (requested 48000Hz) Buffer size range from 2048 to 8192 Period size range from 1024 to 1024 Using max buffer size 8192 Periods = 4 was set period_size = 1024 was set buffer_size = 8192 0 - Front Left Time per period = 2.835792 0 - Front Left Time per period = 2.986653 0 - Front Left Time per period = 2.986654 0 - Front Left ...snip...
I've made sure nothing is muted with the audio hardware by using alsamixer and changed the permissions on the files within the /etc/snd directory. Any other thoughts?
Dave
bump for help
You didn't give any useful information about the hardware itself, so no one can answer. Did it ever sound correctly with any other distro at all?
Please don't mix up the custom-build problem and the driver problem. The problem with silent output is more likely a driver issue (or a configuration issue).
Takashi
The hardware is an integrated HDA Intel audio sound card. The /proc/asound/pcm file has this listed:
00-00: STAC92xx Analog : STAC92xx Analog : playback 1 : capture 2 00-01: STAC92xx Digital : STAC92xx Digital : playback 1 00-03: INTEL HDMI 0 : INTEL HDMI 0 : playback 1
Yes, this audio works just fine within Kubuntu. Here is the output from the 'lsmod' binary:
# lsmod Module Size Used by Not tainted snd_hda_codec_intelhdmi 11040 1 snd_hda_codec_idt 30668 1 snd_hda_intel 14480 0 snd_hda_codec 33296 3 snd_hda_codec_intelhdmi,snd_hda_codec_idt,snd_hda_intel snd_pcm 37628 2 snd_hda_intel,snd_hda_codec snd_page_alloc 4016 2 snd_hda_intel,snd_pcm snd_timer 10564 1 snd_pcm snd 26200 6 snd_hda_codec_intelhdmi,snd_hda_codec_idt,snd_hda_intel,snd_hda_codec,snd_pcm,snd_timer soundcore 2640 1 snd e1000e 82016 0 video 12712 0 output 724 1 video backlight 1632 1 video hid_logitech 2872 0 serio_raw 2380 0
Seems to be getting the drivers loaded correctly, I just have no idea why it's not playing. Also, if I'm missing information to help with a question, please don't just ignore it, but ask me for whatever information you need to help resolve the problem. Sometimes I forget to include certain information or don't know what to post so any of the people here can help fix the issue. :) You guys have waaaaaay more knowledge about this than I do after all. :)
Thanks, Dave
At Wed, 13 Jul 2011 10:25:31 -0400, David Henderson wrote:
On 07/13/2011 10:08 AM, Takashi Iwai wrote:
At Wed, 13 Jul 2011 09:14:55 -0400, David Henderson wrote:
Thanks again for the help Takashi. Ok, I've created the /etc/asound.conf file with the appropriate group and now I'm trying to run the aplay binary and I'm not getting any error messages, but I'm also not hearing any sounds from the speakers.
# aplay freq10-30000-10s.wav Playing WAVE 'freq10-30000-10s.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Mono
# speaker-test -w ./freq10-30000-10s.wav
speaker-test 1.0.23
Playback device is default Stream parameters are 48000Hz, S16_LE, 1 channels Using 16 octaves of pink noise Rate set to 48000Hz (requested 48000Hz) Buffer size range from 2048 to 8192 Period size range from 1024 to 1024 Using max buffer size 8192 Periods = 4 was set period_size = 1024 was set buffer_size = 8192 0 - Front Left Time per period = 2.835792 0 - Front Left Time per period = 2.986653 0 - Front Left Time per period = 2.986654 0 - Front Left ...snip...
I've made sure nothing is muted with the audio hardware by using alsamixer and changed the permissions on the files within the /etc/snd directory. Any other thoughts?
Dave
bump for help
You didn't give any useful information about the hardware itself, so no one can answer. Did it ever sound correctly with any other distro at all?
Please don't mix up the custom-build problem and the driver problem. The problem with silent output is more likely a driver issue (or a configuration issue).
Takashi
The hardware is an integrated HDA Intel audio sound card. The /proc/asound/pcm file has this listed:
00-00: STAC92xx Analog : STAC92xx Analog : playback 1 : capture 2 00-01: STAC92xx Digital : STAC92xx Digital : playback 1 00-03: INTEL HDMI 0 : INTEL HDMI 0 : playback 1
That's not enough. Which kernel / ALSA version, which model option? Could you alsa-info.sh output (run with --no-upload option)? This will give most of needed information.
Yes, this audio works just fine within Kubuntu.
Do both run the same kernel version?
At next, try to run "alsactl -f somefile store" on both systems, and compare the files. You may see some difference in mixer setup.
Takashi
On 07/13/2011 10:31 AM, Takashi Iwai wrote:
At Wed, 13 Jul 2011 10:25:31 -0400, David Henderson wrote:
On 07/13/2011 10:08 AM, Takashi Iwai wrote:
At Wed, 13 Jul 2011 09:14:55 -0400, David Henderson wrote:
Thanks again for the help Takashi. Ok, I've created the /etc/asound.conf file with the appropriate group and now I'm trying to run the aplay binary and I'm not getting any error messages, but I'm also not hearing any sounds from the speakers.
# aplay freq10-30000-10s.wav Playing WAVE 'freq10-30000-10s.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Mono
# speaker-test -w ./freq10-30000-10s.wav
speaker-test 1.0.23
Playback device is default Stream parameters are 48000Hz, S16_LE, 1 channels Using 16 octaves of pink noise Rate set to 48000Hz (requested 48000Hz) Buffer size range from 2048 to 8192 Period size range from 1024 to 1024 Using max buffer size 8192 Periods = 4 was set period_size = 1024 was set buffer_size = 8192 0 - Front Left Time per period = 2.835792 0 - Front Left Time per period = 2.986653 0 - Front Left Time per period = 2.986654 0 - Front Left ...snip...
I've made sure nothing is muted with the audio hardware by using alsamixer and changed the permissions on the files within the /etc/snd directory. Any other thoughts?
Dave
bump for help
You didn't give any useful information about the hardware itself, so no one can answer. Did it ever sound correctly with any other distro at all?
Please don't mix up the custom-build problem and the driver problem. The problem with silent output is more likely a driver issue (or a configuration issue).
Takashi
The hardware is an integrated HDA Intel audio sound card. The /proc/asound/pcm file has this listed:
00-00: STAC92xx Analog : STAC92xx Analog : playback 1 : capture 2 00-01: STAC92xx Digital : STAC92xx Digital : playback 1 00-03: INTEL HDMI 0 : INTEL HDMI 0 : playback 1
That's not enough. Which kernel / ALSA version, which model option? Could you alsa-info.sh output (run with --no-upload option)? This will give most of needed information.
Yes, this audio works just fine within Kubuntu.
Do both run the same kernel version?
At next, try to run "alsactl -f somefile store" on both systems, and compare the files. You may see some difference in mixer setup.
Takashi
I've searched the local fs for the alsa-info.sh script as well as looking through the package contents on debian.org without any results. Where would I get this script from? The kernel running on the custom distro is 2.6.33.3 with an alsa version of 1.0.23. Also, I didn't compile or install the alsa-driver package, but it appears that the drivers are getting loaded for the hardware under the custom distro.
Per the instructions above, I have performed the alsactl command on the working system (Kubuntu) and the custom distro. There are differences in the files which I've attached to this message. Something else I noticed while in the alsamixer for both systems is that there are additional settings on the Kubuntu system as shown below.
Custom Distro: Master, Headphone, Front, Front Mic Jack, Surround, Center, LFE, Side, Mic jack Mode, S/PDIF, S/PDIF Default, S/PDIF Playback, S/PDIF Playback, S/PDIF 1, Swap Center
Kubuntu: Master, Headphone, PCM, Front, Front Mic Jack, Surround, Center, LFE, Side, Mic jack Mode, S/PDIF, S/PDIF Default, S/PDIF Playback, S/PDIF Playback, S/PDIF 1, Beep, Swap Center
Any ideas or other information required to help resolve this problem?
Thanks, Dave
At Fri, 22 Jul 2011 14:23:07 -0400, David Henderson wrote:
[1 <text/plain; ISO-8859-1 (7bit)>] On 07/13/2011 10:31 AM, Takashi Iwai wrote:
At Wed, 13 Jul 2011 10:25:31 -0400, David Henderson wrote:
On 07/13/2011 10:08 AM, Takashi Iwai wrote:
At Wed, 13 Jul 2011 09:14:55 -0400, David Henderson wrote:
Thanks again for the help Takashi. Ok, I've created the /etc/asound.conf file with the appropriate group and now I'm trying to run the aplay binary and I'm not getting any error messages, but I'm also not hearing any sounds from the speakers.
# aplay freq10-30000-10s.wav Playing WAVE 'freq10-30000-10s.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Mono
# speaker-test -w ./freq10-30000-10s.wav
speaker-test 1.0.23
Playback device is default Stream parameters are 48000Hz, S16_LE, 1 channels Using 16 octaves of pink noise Rate set to 48000Hz (requested 48000Hz) Buffer size range from 2048 to 8192 Period size range from 1024 to 1024 Using max buffer size 8192 Periods = 4 was set period_size = 1024 was set buffer_size = 8192 0 - Front Left Time per period = 2.835792 0 - Front Left Time per period = 2.986653 0 - Front Left Time per period = 2.986654 0 - Front Left ...snip...
I've made sure nothing is muted with the audio hardware by using alsamixer and changed the permissions on the files within the /etc/snd directory. Any other thoughts?
Dave
bump for help
You didn't give any useful information about the hardware itself, so no one can answer. Did it ever sound correctly with any other distro at all?
Please don't mix up the custom-build problem and the driver problem. The problem with silent output is more likely a driver issue (or a configuration issue).
Takashi
The hardware is an integrated HDA Intel audio sound card. The /proc/asound/pcm file has this listed:
00-00: STAC92xx Analog : STAC92xx Analog : playback 1 : capture 2 00-01: STAC92xx Digital : STAC92xx Digital : playback 1 00-03: INTEL HDMI 0 : INTEL HDMI 0 : playback 1
That's not enough. Which kernel / ALSA version, which model option? Could you alsa-info.sh output (run with --no-upload option)? This will give most of needed information.
Yes, this audio works just fine within Kubuntu.
Do both run the same kernel version?
At next, try to run "alsactl -f somefile store" on both systems, and compare the files. You may see some difference in mixer setup.
Takashi
I've searched the local fs for the alsa-info.sh script as well as looking through the package contents on debian.org without any results.
See Documentation/sound/alsa/HD-Audio.txt.
Takashi
2011/6/29 David Henderson dhenderson@digital-pipe.com:
Hi gang! I've successfully been able to compile the alsa-utils package with the "--with-alsa-inc-prefix=/opt/staging/alsa/var/share/include --with-alsa-prefix=/opt/staging/alsa/lib", but the problem I'm having now is that the compiled binaries are looking for those directories during run-time and not just compile-time. Does anyone have any thoughts on using those directories for package creation, but that the software doesn't use the '/opt/staging/alsa' prefix during run-time?
Thanks, Dave _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Do you have a full build environment under /opt/staging? If so, you could try to chroot there and configure your software 'normally' instead of passing those parameters... or passing those paths starting from '/' instead of '/opt/staging/' (provided that the final installation will match them, e.g. binaries will look into '/var/share/include' and /lib)... it might work...
If you missed something from the 'real' environment, you could try (before chroot'ing) to create (hard) links to those paths within a 'local' dir (e.g. create dir /opt/staging/extern/ and therein link to /bin, /sbin, /usr/bin etc.) then arrange to have these 'local' paths listed (after chroot'ing) at the end of your PATH env variable. You would need at least a working /opt/staging/bin/sh and perhaps some symlinks, such as a 'lib' pointing to "/alsa/lib" and a 'var' pointing to "/alsa/var", but if such names exist as directories you could need links to each file/subdirectory, perhaps a script could help you creating them on the fly (after chroot'ing) once you knew what you need (e.g. if you need stuff in alsa/var/share/include, arrange your script to work, for instance, with 'alsa' as first parameter and var/share/include as second parameter, then mkdir -p var/share/include and symlink to alsa/var/share/include/<whatever> - if there are subdirs therein, mkdir -p instead of symlinking and move in depth, just in case you needed something from a different <name>/var/share/include/<inner_name>/*). You might also need (sym)links to stuff in extern/<somedir>/ - such a 'dynamic' build environment may become hard to create and handle, more than a full build env for creating a distro from scratch, unless that's what you're doing, just using some code and configurations from an existing distro, in which case maybe you have a full build env yet, so just chroot, compile and install everything both with DESTDIR (to create a package later) and 'normally' (to have include and lib files easy to reuse to match dependencies for building other software).
Or... put your hands into alsa-utils' autogen/automake/configure/script files (if you want an automated process to reuse, or just modify the generated Makefile, if enough) and customize them to achieve what you aim, e.g. setting different -L and -rpath wherever needed, or set and export a global LDFLAGS, taking care to include every library needed and correct paths (use the generated Makefile as a hint), again with different -L and -rpath... or perhaps all you need could be setting the final dirs to look into at runtime in LD_RUN_PATH, in which case you could configure your build as you've done successfully until now, then export (for instance) LD_RUN_PATH=/lib (use the correct path, if you need to include more than one path for shared objects, separate them with a colon, e.g. LD_RUN_PATH=/lib:/var/lib - if I didn't misunderstand, you have some stuff in /var that usually is in /usr/*), then make etc. The latter choice might be the easier, so give it a try, but might not work if your generated Makefile contains -rpath in LDFLAGS...
Regards.
Alex
On 06/30/2011 01:34 PM, alex dot baldacchino dot alsasub at gmail dot com wrote:
2011/6/29 David Hendersondhenderson@digital-pipe.com:
Hi gang! I've successfully been able to compile the alsa-utils package with the "--with-alsa-inc-prefix=/opt/staging/alsa/var/share/include --with-alsa-prefix=/opt/staging/alsa/lib", but the problem I'm having now is that the compiled binaries are looking for those directories during run-time and not just compile-time. Does anyone have any thoughts on using those directories for package creation, but that the software doesn't use the '/opt/staging/alsa' prefix during run-time?
Thanks, Dave _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Do you have a full build environment under /opt/staging? If so, you could try to chroot there and configure your software 'normally' instead of passing those parameters... or passing those paths starting from '/' instead of '/opt/staging/' (provided that the final installation will match them, e.g. binaries will look into '/var/share/include' and /lib)... it might work...
If you missed something from the 'real' environment, you could try (before chroot'ing) to create (hard) links to those paths within a 'local' dir (e.g. create dir /opt/staging/extern/ and therein link to /bin, /sbin, /usr/bin etc.) then arrange to have these 'local' paths listed (after chroot'ing) at the end of your PATH env variable. You would need at least a working /opt/staging/bin/sh and perhaps some symlinks, such as a 'lib' pointing to "/alsa/lib" and a 'var' pointing to "/alsa/var", but if such names exist as directories you could need links to each file/subdirectory, perhaps a script could help you creating them on the fly (after chroot'ing) once you knew what you need (e.g. if you need stuff in alsa/var/share/include, arrange your script to work, for instance, with 'alsa' as first parameter and var/share/include as second parameter, then mkdir -p var/share/include and symlink to alsa/var/share/include/<whatever> - if there are subdirs therein, mkdir -p instead of symlinking and move in depth, just in case you needed something from a different <name>/var/share/include/<inner_name>/*). You might also need (sym)links to stuff in extern/<somedir>/ - such a 'dynamic' build environment may become hard to create and handle, more than a full build env for creating a distro from scratch, unless that's what you're doing, just using some code and configurations from an existing distro, in which case maybe you have a full build env yet, so just chroot, compile and install everything both with DESTDIR (to create a package later) and 'normally' (to have include and lib files easy to reuse to match dependencies for building other software).
Or... put your hands into alsa-utils' autogen/automake/configure/script files (if you want an automated process to reuse, or just modify the generated Makefile, if enough) and customize them to achieve what you aim, e.g. setting different -L and -rpath wherever needed, or set and export a global LDFLAGS, taking care to include every library needed and correct paths (use the generated Makefile as a hint), again with different -L and -rpath... or perhaps all you need could be setting the final dirs to look into at runtime in LD_RUN_PATH, in which case you could configure your build as you've done successfully until now, then export (for instance) LD_RUN_PATH=/lib (use the correct path, if you need to include more than one path for shared objects, separate them with a colon, e.g. LD_RUN_PATH=/lib:/var/lib - if I didn't misunderstand, you have some stuff in /var that usually is in /usr/*), then make etc. The latter choice might be the easier, so give it a try, but might not work if your generated Makefile contains -rpath in LDFLAGS...
Regards.
Alex
Currently I am building a distro from scratch with all the software "installed" to /opt/staging/os - so I guess I do have a build directory. I should be able to chroot into that directory and have everything work correctly (as far as dependencies and such) since I boot to the very same dir hierarchy (obviously minus the /opt/staging/os prefix). I haven't had to do it with any of the software I've compiled so far, but have a few questions regarding this practice. If I chroot into that directory before compiling the software, how will I make all the necessary changes (e.g. PATHs, env values, etc) that are required for the build directory as there are quite a bit of large differences between the main OS and the one I'm building? Also, when chroot'ing, it shouldn't make any changes to the current main OS correct? For example, if I open a terminal window and chroot there, it won't affect the rest of the OS correct? Forgive my ignorance, but I've never had to use chroot and I couldn't find any related info in the man page.
Thanks, Dave
2011/6/30 David Henderson dhenderson@digital-pipe.com:
On 06/30/2011 01:34 PM, alex dot baldacchino dot alsasub at gmail dot com wrote:
2011/6/29 David Hendersondhenderson@digital-pipe.com:
Hi gang! I've successfully been able to compile the alsa-utils package with the "--with-alsa-inc-prefix=/opt/staging/alsa/var/share/include --with-alsa-prefix=/opt/staging/alsa/lib", but the problem I'm having now is that the compiled binaries are looking for those directories during run-time and not just compile-time. Does anyone have any thoughts on using those directories for package creation, but that the software doesn't use the '/opt/staging/alsa' prefix during run-time?
Thanks, Dave _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Do you have a full build environment under /opt/staging? If so, you could try to chroot there and configure your software 'normally' instead of passing those parameters... or passing those paths starting from '/' instead of '/opt/staging/' (provided that the final installation will match them, e.g. binaries will look into '/var/share/include' and /lib)... it might work...
If you missed something from the 'real' environment, you could try (before chroot'ing) to create (hard) links to those paths within a 'local' dir (e.g. create dir /opt/staging/extern/ and therein link to /bin, /sbin, /usr/bin etc.) then arrange to have these 'local' paths listed (after chroot'ing) at the end of your PATH env variable. You would need at least a working /opt/staging/bin/sh and perhaps some symlinks, such as a 'lib' pointing to "/alsa/lib" and a 'var' pointing to "/alsa/var", but if such names exist as directories you could need links to each file/subdirectory, perhaps a script could help you creating them on the fly (after chroot'ing) once you knew what you need (e.g. if you need stuff in alsa/var/share/include, arrange your script to work, for instance, with 'alsa' as first parameter and var/share/include as second parameter, then mkdir -p var/share/include and symlink to alsa/var/share/include/<whatever> - if there are subdirs therein, mkdir -p instead of symlinking and move in depth, just in case you needed something from a different <name>/var/share/include/<inner_name>/*). You might also need (sym)links to stuff in extern/<somedir>/ - such a 'dynamic' build environment may become hard to create and handle, more than a full build env for creating a distro from scratch, unless that's what you're doing, just using some code and configurations from an existing distro, in which case maybe you have a full build env yet, so just chroot, compile and install everything both with DESTDIR (to create a package later) and 'normally' (to have include and lib files easy to reuse to match dependencies for building other software).
Or... put your hands into alsa-utils' autogen/automake/configure/script files (if you want an automated process to reuse, or just modify the generated Makefile, if enough) and customize them to achieve what you aim, e.g. setting different -L and -rpath wherever needed, or set and export a global LDFLAGS, taking care to include every library needed and correct paths (use the generated Makefile as a hint), again with different -L and -rpath... or perhaps all you need could be setting the final dirs to look into at runtime in LD_RUN_PATH, in which case you could configure your build as you've done successfully until now, then export (for instance) LD_RUN_PATH=/lib (use the correct path, if you need to include more than one path for shared objects, separate them with a colon, e.g. LD_RUN_PATH=/lib:/var/lib - if I didn't misunderstand, you have some stuff in /var that usually is in /usr/*), then make etc. The latter choice might be the easier, so give it a try, but might not work if your generated Makefile contains -rpath in LDFLAGS...
Regards.
Alex
Currently I am building a distro from scratch with all the software "installed" to /opt/staging/os - so I guess I do have a build directory. I should be able to chroot into that directory and have everything work correctly (as far as dependencies and such) since I boot to the very same dir hierarchy (obviously minus the /opt/staging/os prefix). I haven't had to do it with any of the software I've compiled so far, but have a few questions regarding this practice. If I chroot into that directory before compiling the software, how will I make all the necessary changes (e.g. PATHs, env values, etc) that are required for the build directory as there are quite a bit of large differences between the main OS and the one I'm building? Also, when chroot'ing, it shouldn't make any changes to the current main OS correct? For example, if I open a terminal window and chroot there, it won't affect the rest of the OS correct? Forgive my ignorance, but I've never had to use chroot and I couldn't find any related info in the man page.
Thanks, Dave
I'm not an expert in building distros, but there are several good guides on the net, both for 'normal' and embedded systems. For instance, you could give a look at http://www.linuxfromscratch.org/ and take hints on the path you need to follow to create your distro.
About chroot, think of it as creating a sort of 'sandbox' where you do anything without affecting the 'external world' - you're inside /opt/staging/ but you're calling it / no more (or better, there is more: you can access about only stuff within /opt/staging/ tree - but read further), so, if you load or modify a file called, say, /etc/.somethingrc, you're working with /opt/staging/etc/.somethingrc, not the 'external OS' /etc/.somethingrc, unless the one in /opt/staging is (e.g.) a hardlink to it. AFAICT, it's been for ages the usual way (used together with pivot_root) to pass from early user-space to the 'main' system during boot-up, specially when initial ramdisks where used to boot, now, with initramfs/cpio archives, it's common to find switch_root/new_root being used instead, specially for those small distros (but not only) build around busybox (switch_root - new_root is the counterpart offered by klibc) -- do not use such commands in place of chroot for your purpose, because they can be disruptive!
Changing environment variables is generally harmless (from this point of view), changes apply from the 'point' they're made and exported. For instance, if you modify the content of PATH in an xterm, you'll find the 'old' content in another one. That's the same for a chroot env, but with a difference: you shouldn't be allowed to see the 'real OS' envs (specially files, such as /etc/groups, unless you use mount --bind, but I think hardlinks should work too), so you should need to create them, and anyway, what you modify within the chroot environment applies to the chroot environment (unless arranging to touch something out of it, but you need do it purposely for it to happen - but read further). But beware two things: first, you're still using the same kernel and (loaded) modules, so, if your new distro embeds a more recent kernel version and any of the software you're building relies upon new functionalities provided by the newer kernel, you may found troubles testing such software, though you should be still able to compile it; second, what chroot really does is changing the way an absolute path is resolved: if you cd to /bin after chroot'ing to /opt/staging, you're entering /opt/staging/bin, but if you use relative paths you may happen to touch something outside the chroot env, so you'd need to cd /opt/staging before invoking chroot. You might set envs with a 'local' (and eventually minimal) init script, so that, for instance, you would execute:
cd /opt/staging chroot /opt/staging # this typically invokes /bin/sh -i, that is /opt/staging/bin/sh -i /init_env.sh # if you have proper files (passwd, groups, .bashrc and so on under /opt/staging/etc you might not need this, or you might use it for additional customization)
(remember to avoid using relative paths as ../somename, or check pwd is not '/' before doing so if in doubt on your position, because you might happen to escape from the chroot jail)
You can find more infos at http://xpt.sourceforge.net/techdocs/nix/chroot/ - http://en.wikipedia.org/wiki/Chroot - http://www.bpfh.net/simes/computing/chroot-break.html
Regards.
Alex
On 06/30/2011 08:48 PM, alex dot baldacchino dot alsasub at gmail dot com wrote:
2011/6/30 David Hendersondhenderson@digital-pipe.com:
On 06/30/2011 01:34 PM, alex dot baldacchino dot alsasub at gmail dot com wrote:
2011/6/29 David Hendersondhenderson@digital-pipe.com:
Hi gang! I've successfully been able to compile the alsa-utils package with the "--with-alsa-inc-prefix=/opt/staging/alsa/var/share/include --with-alsa-prefix=/opt/staging/alsa/lib", but the problem I'm having now is that the compiled binaries are looking for those directories during run-time and not just compile-time. Does anyone have any thoughts on using those directories for package creation, but that the software doesn't use the '/opt/staging/alsa' prefix during run-time?
Thanks, Dave _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Do you have a full build environment under /opt/staging? If so, you could try to chroot there and configure your software 'normally' instead of passing those parameters... or passing those paths starting from '/' instead of '/opt/staging/' (provided that the final installation will match them, e.g. binaries will look into '/var/share/include' and /lib)... it might work...
If you missed something from the 'real' environment, you could try (before chroot'ing) to create (hard) links to those paths within a 'local' dir (e.g. create dir /opt/staging/extern/ and therein link to /bin, /sbin, /usr/bin etc.) then arrange to have these 'local' paths listed (after chroot'ing) at the end of your PATH env variable. You would need at least a working /opt/staging/bin/sh and perhaps some symlinks, such as a 'lib' pointing to "/alsa/lib" and a 'var' pointing to "/alsa/var", but if such names exist as directories you could need links to each file/subdirectory, perhaps a script could help you creating them on the fly (after chroot'ing) once you knew what you need (e.g. if you need stuff in alsa/var/share/include, arrange your script to work, for instance, with 'alsa' as first parameter and var/share/include as second parameter, then mkdir -p var/share/include and symlink to alsa/var/share/include/<whatever> - if there are subdirs therein, mkdir -p instead of symlinking and move in depth, just in case you needed something from a different <name>/var/share/include/<inner_name>/*). You might also need (sym)links to stuff in extern/<somedir>/ - such a 'dynamic' build environment may become hard to create and handle, more than a full build env for creating a distro from scratch, unless that's what you're doing, just using some code and configurations from an existing distro, in which case maybe you have a full build env yet, so just chroot, compile and install everything both with DESTDIR (to create a package later) and 'normally' (to have include and lib files easy to reuse to match dependencies for building other software).
Or... put your hands into alsa-utils' autogen/automake/configure/script files (if you want an automated process to reuse, or just modify the generated Makefile, if enough) and customize them to achieve what you aim, e.g. setting different -L and -rpath wherever needed, or set and export a global LDFLAGS, taking care to include every library needed and correct paths (use the generated Makefile as a hint), again with different -L and -rpath... or perhaps all you need could be setting the final dirs to look into at runtime in LD_RUN_PATH, in which case you could configure your build as you've done successfully until now, then export (for instance) LD_RUN_PATH=/lib (use the correct path, if you need to include more than one path for shared objects, separate them with a colon, e.g. LD_RUN_PATH=/lib:/var/lib - if I didn't misunderstand, you have some stuff in /var that usually is in /usr/*), then make etc. The latter choice might be the easier, so give it a try, but might not work if your generated Makefile contains -rpath in LDFLAGS...
Regards.
Alex
Currently I am building a distro from scratch with all the software "installed" to /opt/staging/os - so I guess I do have a build directory. I should be able to chroot into that directory and have everything work correctly (as far as dependencies and such) since I boot to the very same dir hierarchy (obviously minus the /opt/staging/os prefix). I haven't had to do it with any of the software I've compiled so far, but have a few questions regarding this practice. If I chroot into that directory before compiling the software, how will I make all the necessary changes (e.g. PATHs, env values, etc) that are required for the build directory as there are quite a bit of large differences between the main OS and the one I'm building? Also, when chroot'ing, it shouldn't make any changes to the current main OS correct? For example, if I open a terminal window and chroot there, it won't affect the rest of the OS correct? Forgive my ignorance, but I've never had to use chroot and I couldn't find any related info in the man page.
Thanks, Dave
I'm not an expert in building distros, but there are several good guides on the net, both for 'normal' and embedded systems. For instance, you could give a look at http://www.linuxfromscratch.org/ and take hints on the path you need to follow to create your distro.
About chroot, think of it as creating a sort of 'sandbox' where you do anything without affecting the 'external world' - you're inside /opt/staging/ but you're calling it / no more (or better, there is more: you can access about only stuff within /opt/staging/ tree - but read further), so, if you load or modify a file called, say, /etc/.somethingrc, you're working with /opt/staging/etc/.somethingrc, not the 'external OS' /etc/.somethingrc, unless the one in /opt/staging is (e.g.) a hardlink to it. AFAICT, it's been for ages the usual way (used together with pivot_root) to pass from early user-space to the 'main' system during boot-up, specially when initial ramdisks where used to boot, now, with initramfs/cpio archives, it's common to find switch_root/new_root being used instead, specially for those small distros (but not only) build around busybox (switch_root - new_root is the counterpart offered by klibc) -- do not use such commands in place of chroot for your purpose, because they can be disruptive!
Changing environment variables is generally harmless (from this point of view), changes apply from the 'point' they're made and exported. For instance, if you modify the content of PATH in an xterm, you'll find the 'old' content in another one. That's the same for a chroot env, but with a difference: you shouldn't be allowed to see the 'real OS' envs (specially files, such as /etc/groups, unless you use mount --bind, but I think hardlinks should work too), so you should need to create them, and anyway, what you modify within the chroot environment applies to the chroot environment (unless arranging to touch something out of it, but you need do it purposely for it to happen - but read further). But beware two things: first, you're still using the same kernel and (loaded) modules, so, if your new distro embeds a more recent kernel version and any of the software you're building relies upon new functionalities provided by the newer kernel, you may found troubles testing such software, though you should be still able to compile it; second, what chroot really does is changing the way an absolute path is resolved: if you cd to /bin after chroot'ing to /opt/staging, you're entering /opt/staging/bin, but if you use relative paths you may happen to touch something outside the chroot env, so you'd need to cd /opt/staging before invoking chroot. You might set envs with a 'local' (and eventually minimal) init script, so that, for instance, you would execute:
cd /opt/staging chroot /opt/staging # this typically invokes /bin/sh -i, that is /opt/staging/bin/sh -i /init_env.sh # if you have proper files (passwd, groups, .bashrc and so on under /opt/staging/etc you might not need this, or you might use it for additional customization)
(remember to avoid using relative paths as ../somename, or check pwd is not '/' before doing so if in doubt on your position, because you might happen to escape from the chroot jail)
You can find more infos at http://xpt.sourceforge.net/techdocs/nix/chroot/ - http://en.wikipedia.org/wiki/Chroot - http://www.bpfh.net/simes/computing/chroot-break.html
Regards.
Alex
Hey Alex, thanks for the help. Seeing as how it would take quite a bit of work to setup the "sandbox", I wanted to see if there was an easier way. Because this custom distro keeps some files in non-standard locations, I determined I could just symlink the requested files in my existing build distro (Kubuntu). I was successful at getting alsa-utils to compile, however, I'm still getting the following error when trying to run amixer:
ALSA lib conf.c:3601:(snd_config_update_r) Cannot access file /opt/staging/package/var/share/alsa/alsa.conf ALSA lib control.c:902:(snd_ctl_open_noupdate) Invalid CTL default amixer: Mixer attach default error: No such file or directory
The mind boggling part is, that directory isn't specified anywhere other than the DESTDIR variable value with 'make'. Why would alsa be hard coding that value within the compiled binaries? Isn't that variable used for package creation so that 'real' directories can be specified while also providing a 'fake' install directory (via DESTDIR)?
Thanks, Dave
participants (4)
-
alex dot baldacchino dot alsasub at gmail dot com -
David Henderson -
Lu Guanqun -
Takashi Iwai