* additional problem
@ 2011-06-29 13:57 David Henderson
2011-06-30 12:15 ` David Henderson
2011-06-30 17:34 ` alex dot baldacchino dot alsasub at gmail dot com
0 siblings, 2 replies; 26+ messages in thread
From: David Henderson @ 2011-06-29 13:57 UTC (permalink / raw)
To: alsa-devel
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: additional problem
2011-06-29 13:57 additional problem David Henderson
@ 2011-06-30 12:15 ` David Henderson
2011-06-30 15:43 ` David Henderson
2011-07-01 6:41 ` Takashi Iwai
2011-06-30 17:34 ` alex dot baldacchino dot alsasub at gmail dot com
1 sibling, 2 replies; 26+ messages in thread
From: David Henderson @ 2011-06-30 12:15 UTC (permalink / raw)
To: alsa-devel
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: additional problem
2011-06-30 12:15 ` David Henderson
@ 2011-06-30 15:43 ` David Henderson
2011-06-30 17:01 ` Lu Guanqun
2011-07-01 6:41 ` Takashi Iwai
1 sibling, 1 reply; 26+ messages in thread
From: David Henderson @ 2011-06-30 15:43 UTC (permalink / raw)
To: alsa-devel
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: additional problem
2011-06-30 15:43 ` David Henderson
@ 2011-06-30 17:01 ` Lu Guanqun
0 siblings, 0 replies; 26+ messages in thread
From: Lu Guanqun @ 2011-06-30 17:01 UTC (permalink / raw)
To: David Henderson; +Cc: alsa-devel
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
--
guanqun
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: additional problem
2011-06-29 13:57 additional problem David Henderson
2011-06-30 12:15 ` David Henderson
@ 2011-06-30 17:34 ` alex dot baldacchino dot alsasub at gmail dot com
2011-06-30 19:02 ` David Henderson
1 sibling, 1 reply; 26+ messages in thread
From: alex dot baldacchino dot alsasub at gmail dot com @ 2011-06-30 17:34 UTC (permalink / raw)
To: David Henderson; +Cc: alsa-devel
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: additional problem
2011-06-30 17:34 ` alex dot baldacchino dot alsasub at gmail dot com
@ 2011-06-30 19:02 ` David Henderson
2011-07-01 0:48 ` alex dot baldacchino dot alsasub at gmail dot com
0 siblings, 1 reply; 26+ messages in thread
From: David Henderson @ 2011-06-30 19:02 UTC (permalink / raw)
To: alex dot baldacchino dot alsasub at gmail dot com; +Cc: alsa-devel
On 06/30/2011 01:34 PM, alex dot baldacchino dot alsasub at gmail dot
com wrote:
> 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
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: additional problem
2011-06-30 19:02 ` David Henderson
@ 2011-07-01 0:48 ` alex dot baldacchino dot alsasub at gmail dot com
2011-07-11 14:32 ` David Henderson
0 siblings, 1 reply; 26+ messages in thread
From: alex dot baldacchino dot alsasub at gmail dot com @ 2011-07-01 0:48 UTC (permalink / raw)
To: David Henderson; +Cc: alsa-devel
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 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
>
> 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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: additional problem
2011-06-30 12:15 ` David Henderson
2011-06-30 15:43 ` David Henderson
@ 2011-07-01 6:41 ` Takashi Iwai
2011-07-11 14:26 ` David Henderson
1 sibling, 1 reply; 26+ messages in thread
From: Takashi Iwai @ 2011-07-01 6:41 UTC (permalink / raw)
To: David Henderson; +Cc: 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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: additional problem
2011-07-01 6:41 ` Takashi Iwai
@ 2011-07-11 14:26 ` David Henderson
2011-07-11 14:43 ` Takashi Iwai
0 siblings, 1 reply; 26+ messages in thread
From: David Henderson @ 2011-07-11 14:26 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: additional problem
2011-07-01 0:48 ` alex dot baldacchino dot alsasub at gmail dot com
@ 2011-07-11 14:32 ` David Henderson
0 siblings, 0 replies; 26+ messages in thread
From: David Henderson @ 2011-07-11 14:32 UTC (permalink / raw)
To: alex dot baldacchino dot alsasub at gmail dot com; +Cc: alsa-devel
On 06/30/2011 08:48 PM, alex dot baldacchino dot alsasub at gmail dot
com wrote:
> 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 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
>> 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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: additional problem
2011-07-11 14:26 ` David Henderson
@ 2011-07-11 14:43 ` Takashi Iwai
2011-07-11 15:05 ` David Henderson
0 siblings, 1 reply; 26+ messages in thread
From: Takashi Iwai @ 2011-07-11 14:43 UTC (permalink / raw)
To: David Henderson; +Cc: alsa-devel
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: additional problem
2011-07-11 14:43 ` Takashi Iwai
@ 2011-07-11 15:05 ` David Henderson
2011-07-11 15:12 ` Takashi Iwai
0 siblings, 1 reply; 26+ messages in thread
From: David Henderson @ 2011-07-11 15:05 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: additional problem
2011-07-11 15:05 ` David Henderson
@ 2011-07-11 15:12 ` Takashi Iwai
2011-07-11 15:13 ` David Henderson
0 siblings, 1 reply; 26+ messages in thread
From: Takashi Iwai @ 2011-07-11 15:12 UTC (permalink / raw)
To: David Henderson; +Cc: alsa-devel
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: additional problem
2011-07-11 15:12 ` Takashi Iwai
@ 2011-07-11 15:13 ` David Henderson
2011-07-11 15:17 ` Takashi Iwai
0 siblings, 1 reply; 26+ messages in thread
From: David Henderson @ 2011-07-11 15:13 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: additional problem
2011-07-11 15:13 ` David Henderson
@ 2011-07-11 15:17 ` Takashi Iwai
2011-07-11 15:25 ` David Henderson
0 siblings, 1 reply; 26+ messages in thread
From: Takashi Iwai @ 2011-07-11 15:17 UTC (permalink / raw)
To: David Henderson; +Cc: alsa-devel
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: additional problem
2011-07-11 15:17 ` Takashi Iwai
@ 2011-07-11 15:25 ` David Henderson
2011-07-11 15:52 ` Takashi Iwai
0 siblings, 1 reply; 26+ messages in thread
From: David Henderson @ 2011-07-11 15:25 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: additional problem
2011-07-11 15:25 ` David Henderson
@ 2011-07-11 15:52 ` Takashi Iwai
2011-07-12 13:05 ` David Henderson
0 siblings, 1 reply; 26+ messages in thread
From: Takashi Iwai @ 2011-07-11 15:52 UTC (permalink / raw)
To: David Henderson; +Cc: alsa-devel
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: additional problem
2011-07-11 15:52 ` Takashi Iwai
@ 2011-07-12 13:05 ` David Henderson
2011-07-12 13:13 ` Takashi Iwai
0 siblings, 1 reply; 26+ messages in thread
From: David Henderson @ 2011-07-12 13:05 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: additional problem
2011-07-12 13:05 ` David Henderson
@ 2011-07-12 13:13 ` Takashi Iwai
2011-07-12 13:30 ` David Henderson
0 siblings, 1 reply; 26+ messages in thread
From: Takashi Iwai @ 2011-07-12 13:13 UTC (permalink / raw)
To: David Henderson; +Cc: alsa-devel
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: additional problem
2011-07-12 13:13 ` Takashi Iwai
@ 2011-07-12 13:30 ` David Henderson
2011-07-13 13:14 ` David Henderson
0 siblings, 1 reply; 26+ messages in thread
From: David Henderson @ 2011-07-12 13:30 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: additional problem
2011-07-12 13:30 ` David Henderson
@ 2011-07-13 13:14 ` David Henderson
2011-07-13 14:08 ` Takashi Iwai
0 siblings, 1 reply; 26+ messages in thread
From: David Henderson @ 2011-07-13 13:14 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: additional problem
2011-07-13 13:14 ` David Henderson
@ 2011-07-13 14:08 ` Takashi Iwai
2011-07-13 14:25 ` David Henderson
0 siblings, 1 reply; 26+ messages in thread
From: Takashi Iwai @ 2011-07-13 14:08 UTC (permalink / raw)
To: David Henderson; +Cc: alsa-devel
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: additional problem
2011-07-13 14:08 ` Takashi Iwai
@ 2011-07-13 14:25 ` David Henderson
2011-07-13 14:31 ` Takashi Iwai
0 siblings, 1 reply; 26+ messages in thread
From: David Henderson @ 2011-07-13 14:25 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: additional problem
2011-07-13 14:25 ` David Henderson
@ 2011-07-13 14:31 ` Takashi Iwai
2011-07-22 18:23 ` David Henderson
0 siblings, 1 reply; 26+ messages in thread
From: Takashi Iwai @ 2011-07-13 14:31 UTC (permalink / raw)
To: David Henderson; +Cc: alsa-devel
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: additional problem
2011-07-13 14:31 ` Takashi Iwai
@ 2011-07-22 18:23 ` David Henderson
2011-07-22 19:24 ` Takashi Iwai
0 siblings, 1 reply; 26+ messages in thread
From: David Henderson @ 2011-07-22 18:23 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel
[-- Attachment #1: Type: text/plain, Size: 3820 bytes --]
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
[-- Attachment #2: custom_sound.txt --]
[-- Type: text/plain, Size: 8809 bytes --]
state.Intel {
control.1 {
comment.access 'read write'
comment.type INTEGER
comment.count 2
comment.range '0 - 64'
comment.dbmin -4800
comment.dbmax 0
iface MIXER
name 'Front Playback Volume'
value.0 64
value.1 64
}
control.2 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 2
iface MIXER
name 'Front Playback Switch'
value.0 true
value.1 true
}
control.3 {
comment.access 'read write'
comment.type INTEGER
comment.count 2
comment.range '0 - 64'
comment.dbmin -4800
comment.dbmax 0
iface MIXER
name 'Surround Playback Volume'
value.0 64
value.1 64
}
control.4 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 2
iface MIXER
name 'Surround Playback Switch'
value.0 true
value.1 true
}
control.5 {
comment.access 'read write'
comment.type INTEGER
comment.count 1
comment.range '0 - 64'
comment.dbmin -4800
comment.dbmax 0
iface MIXER
name 'Center Playback Volume'
value 64
}
control.6 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 1
iface MIXER
name 'Center Playback Switch'
value true
}
control.7 {
comment.access 'read write'
comment.type INTEGER
comment.count 1
comment.range '0 - 64'
comment.dbmin -4800
comment.dbmax 0
iface MIXER
name 'LFE Playback Volume'
value 64
}
control.8 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 1
iface MIXER
name 'LFE Playback Switch'
value true
}
control.9 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 1
iface MIXER
name 'Swap Center/LFE Playback Switch'
value true
}
control.10 {
comment.access 'read write'
comment.type INTEGER
comment.count 2
comment.range '0 - 64'
comment.dbmin -4800
comment.dbmax 0
iface MIXER
name 'Side Playback Volume'
value.0 64
value.1 64
}
control.11 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 2
iface MIXER
name 'Side Playback Switch'
value.0 true
value.1 true
}
control.12 {
comment.access 'read write'
comment.type ENUMERATED
comment.count 1
comment.item.0 'Mic In'
comment.item.1 'Line In'
iface MIXER
name 'Mic Jack Mode'
value 'Mic In'
}
control.13 {
comment.access 'read write'
comment.type ENUMERATED
comment.count 1
comment.item.0 'Mic In'
comment.item.1 'Line In'
iface MIXER
name 'Front Mic Jack Mode'
value 'Mic In'
}
control.14 {
comment.access 'read write'
comment.type INTEGER
comment.count 2
comment.range '0 - 64'
comment.dbmin -4800
comment.dbmax 0
iface MIXER
name 'Headphone Playback Volume'
value.0 64
value.1 64
}
control.15 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 2
iface MIXER
name 'Headphone Playback Switch'
value.0 true
value.1 true
}
control.16 {
comment.access 'read write'
comment.type INTEGER
comment.count 2
comment.range '0 - 15'
comment.dbmin 0
comment.dbmax 2250
iface MIXER
name 'Capture Volume'
value.0 0
value.1 0
}
control.17 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 2
iface MIXER
name 'Capture Switch'
value.0 false
value.1 false
}
control.18 {
comment.access 'read write'
comment.type INTEGER
comment.count 2
comment.range '0 - 15'
comment.dbmin 0
comment.dbmax 2250
iface MIXER
name 'Capture Volume'
index 1
value.0 0
value.1 0
}
control.19 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 2
iface MIXER
name 'Capture Switch'
index 1
value.0 false
value.1 false
}
control.20 {
comment.access 'read write'
comment.type INTEGER
comment.count 2
comment.range '0 - 3'
comment.dbmin 0
comment.dbmax 3000
iface MIXER
name 'Mic Capture Volume'
value.0 0
value.1 0
}
control.21 {
comment.access 'read write'
comment.type INTEGER
comment.count 2
comment.range '0 - 3'
comment.dbmin 0
comment.dbmax 3000
iface MIXER
name 'Front Mic Capture Volume'
value.0 0
value.1 0
}
control.22 {
comment.access 'read write'
comment.type ENUMERATED
comment.count 1
comment.item.0 Mic
comment.item.1 'Front Mic'
iface MIXER
name 'Input Source'
value Mic
}
control.23 {
comment.access 'read write'
comment.type ENUMERATED
comment.count 1
comment.item.0 Mic
comment.item.1 'Front Mic'
iface MIXER
name 'Input Source'
index 1
value Mic
}
control.24 {
comment.access 'read write'
comment.type ENUMERATED
comment.count 1
comment.item.0 'Digital Playback'
comment.item.1 'Analog Mux 1'
comment.item.2 'Analog Mux 2'
comment.item.3 Off
iface MIXER
name 'IEC958 Playback Source'
value 'Digital Playback'
}
control.25 {
comment.access 'read write'
comment.type ENUMERATED
comment.count 1
comment.item.0 'Digital Playback'
comment.item.1 'Analog Mux 1'
comment.item.2 'Analog Mux 2'
comment.item.3 Off
iface MIXER
name 'IEC958 Playback Source'
index 1
value 'Digital Playback'
}
control.26 {
comment.access read
comment.type IEC958
comment.count 1
iface MIXER
name 'IEC958 Playback Con Mask'
value '0fff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
}
control.27 {
comment.access read
comment.type IEC958
comment.count 1
iface MIXER
name 'IEC958 Playback Pro Mask'
value '0f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
}
control.28 {
comment.access 'read write'
comment.type IEC958
comment.count 1
iface MIXER
name 'IEC958 Playback Default'
value '0400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
}
control.29 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 1
iface MIXER
name 'IEC958 Playback Switch'
value true
}
control.30 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 1
iface MIXER
name 'IEC958 Default PCM Playback Switch'
value true
}
control.31 {
comment.access 'read write'
comment.type INTEGER
comment.count 1
comment.range '0 - 64'
comment.dbmin -4800
comment.dbmax 0
iface MIXER
name 'Master Playback Volume'
value 64
}
control.32 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 1
iface MIXER
name 'Master Playback Switch'
value true
}
control.33 {
comment.access read
comment.type IEC958
comment.count 1
iface MIXER
name 'IEC958 Playback Con Mask'
index 1
value '0fff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
}
control.34 {
comment.access read
comment.type IEC958
comment.count 1
iface MIXER
name 'IEC958 Playback Pro Mask'
index 1
value '0f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
}
control.35 {
comment.access 'read write'
comment.type IEC958
comment.count 1
iface MIXER
name 'IEC958 Playback Default'
index 1
value '0400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
}
control.36 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 1
iface MIXER
name 'IEC958 Playback Switch'
index 1
value true
}
}
[-- Attachment #3: kubuntu_sound.txt --]
[-- Type: text/plain, Size: 9446 bytes --]
state.Intel {
control.1 {
comment.access 'read write'
comment.type INTEGER
comment.count 2
comment.range '0 - 64'
comment.dbmin -4800
comment.dbmax 0
iface MIXER
name 'Front Playback Volume'
value.0 52
value.1 52
}
control.2 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 2
iface MIXER
name 'Front Playback Switch'
value.0 true
value.1 true
}
control.3 {
comment.access 'read write'
comment.type INTEGER
comment.count 2
comment.range '0 - 64'
comment.dbmin -4800
comment.dbmax 0
iface MIXER
name 'Surround Playback Volume'
value.0 64
value.1 64
}
control.4 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 2
iface MIXER
name 'Surround Playback Switch'
value.0 false
value.1 false
}
control.5 {
comment.access 'read write'
comment.type INTEGER
comment.count 1
comment.range '0 - 64'
comment.dbmin -4800
comment.dbmax 0
iface MIXER
name 'Center Playback Volume'
value 64
}
control.6 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 1
iface MIXER
name 'Center Playback Switch'
value false
}
control.7 {
comment.access 'read write'
comment.type INTEGER
comment.count 1
comment.range '0 - 64'
comment.dbmin -4800
comment.dbmax 0
iface MIXER
name 'LFE Playback Volume'
value 64
}
control.8 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 1
iface MIXER
name 'LFE Playback Switch'
value false
}
control.9 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 1
iface MIXER
name 'Swap Center/LFE Playback Switch'
value false
}
control.10 {
comment.access 'read write'
comment.type INTEGER
comment.count 2
comment.range '0 - 64'
comment.dbmin -4800
comment.dbmax 0
iface MIXER
name 'Side Playback Volume'
value.0 64
value.1 64
}
control.11 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 2
iface MIXER
name 'Side Playback Switch'
value.0 false
value.1 false
}
control.12 {
comment.access 'read write'
comment.type ENUMERATED
comment.count 1
comment.item.0 'Mic In'
comment.item.1 'Line In'
iface MIXER
name 'Mic Jack Mode'
value 'Mic In'
}
control.13 {
comment.access 'read write'
comment.type ENUMERATED
comment.count 1
comment.item.0 'Mic In'
comment.item.1 'Line In'
iface MIXER
name 'Front Mic Jack Mode'
value 'Mic In'
}
control.14 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 1
iface MIXER
name 'Beep Playback Switch'
value true
}
control.15 {
comment.access 'read write'
comment.type INTEGER
comment.count 1
comment.range '0 - 3'
comment.dbmin -1800
comment.dbmax 0
iface MIXER
name 'Beep Playback Volume'
value 1
}
control.16 {
comment.access 'read write'
comment.type INTEGER
comment.count 2
comment.range '0 - 64'
comment.dbmin -4800
comment.dbmax 0
iface MIXER
name 'Headphone Playback Volume'
value.0 64
value.1 64
}
control.17 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 2
iface MIXER
name 'Headphone Playback Switch'
value.0 true
value.1 true
}
control.18 {
comment.access 'read write'
comment.type INTEGER
comment.count 2
comment.range '0 - 15'
comment.dbmin 0
comment.dbmax 2250
iface MIXER
name 'Capture Volume'
value.0 0
value.1 0
}
control.19 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 2
iface MIXER
name 'Capture Switch'
value.0 false
value.1 false
}
control.20 {
comment.access 'read write'
comment.type INTEGER
comment.count 2
comment.range '0 - 15'
comment.dbmin 0
comment.dbmax 2250
iface MIXER
name 'Capture Volume'
index 1
value.0 0
value.1 0
}
control.21 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 2
iface MIXER
name 'Capture Switch'
index 1
value.0 false
value.1 false
}
control.22 {
comment.access 'read write'
comment.type INTEGER
comment.count 2
comment.range '0 - 3'
comment.dbmin 0
comment.dbmax 3000
iface MIXER
name 'Mic Capture Volume'
value.0 0
value.1 0
}
control.23 {
comment.access 'read write'
comment.type INTEGER
comment.count 2
comment.range '0 - 3'
comment.dbmin 0
comment.dbmax 3000
iface MIXER
name 'Front Mic Capture Volume'
value.0 0
value.1 0
}
control.24 {
comment.access 'read write'
comment.type ENUMERATED
comment.count 1
comment.item.0 Mic
comment.item.1 'Front Mic'
iface MIXER
name 'Input Source'
value Mic
}
control.25 {
comment.access 'read write'
comment.type ENUMERATED
comment.count 1
comment.item.0 Mic
comment.item.1 'Front Mic'
iface MIXER
name 'Input Source'
index 1
value Mic
}
control.26 {
comment.access 'read write'
comment.type ENUMERATED
comment.count 1
comment.item.0 'Digital Playback'
comment.item.1 'Analog Mux 1'
comment.item.2 'Analog Mux 2'
comment.item.3 Off
iface MIXER
name 'IEC958 Playback Source'
value 'Digital Playback'
}
control.27 {
comment.access 'read write'
comment.type ENUMERATED
comment.count 1
comment.item.0 'Digital Playback'
comment.item.1 'Analog Mux 1'
comment.item.2 'Analog Mux 2'
comment.item.3 Off
iface MIXER
name 'IEC958 Playback Source'
index 1
value 'Digital Playback'
}
control.28 {
comment.access read
comment.type IEC958
comment.count 1
iface MIXER
name 'IEC958 Playback Con Mask'
value '0fff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
}
control.29 {
comment.access read
comment.type IEC958
comment.count 1
iface MIXER
name 'IEC958 Playback Pro Mask'
value '0f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
}
control.30 {
comment.access 'read write'
comment.type IEC958
comment.count 1
iface MIXER
name 'IEC958 Playback Default'
value '0400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
}
control.31 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 1
iface MIXER
name 'IEC958 Playback Switch'
value true
}
control.32 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 1
iface MIXER
name 'IEC958 Default PCM Playback Switch'
value true
}
control.33 {
comment.access 'read write'
comment.type INTEGER
comment.count 1
comment.range '0 - 64'
comment.dbmin -4800
comment.dbmax 0
iface MIXER
name 'Master Playback Volume'
value 52
}
control.34 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 1
iface MIXER
name 'Master Playback Switch'
value true
}
control.35 {
comment.access read
comment.type IEC958
comment.count 1
iface MIXER
name 'IEC958 Playback Con Mask'
index 1
value '0fff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
}
control.36 {
comment.access read
comment.type IEC958
comment.count 1
iface MIXER
name 'IEC958 Playback Pro Mask'
index 1
value '0f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
}
control.37 {
comment.access 'read write'
comment.type IEC958
comment.count 1
iface MIXER
name 'IEC958 Playback Default'
index 1
value '0400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
}
control.38 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 1
iface MIXER
name 'IEC958 Playback Switch'
index 1
value true
}
control.39 {
comment.access 'read write user'
comment.type INTEGER
comment.count 2
comment.range '0 - 255'
comment.tlv '0000000100000008ffffec1400000014'
comment.dbmin -5100
comment.dbmax 0
iface MIXER
name 'PCM Playback Volume'
value.0 255
value.1 255
}
}
[-- Attachment #4: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: additional problem
2011-07-22 18:23 ` David Henderson
@ 2011-07-22 19:24 ` Takashi Iwai
0 siblings, 0 replies; 26+ messages in thread
From: Takashi Iwai @ 2011-07-22 19:24 UTC (permalink / raw)
To: David Henderson; +Cc: alsa-devel
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
^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2011-07-22 19:24 UTC | newest]
Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-06-29 13:57 additional problem David Henderson
2011-06-30 12:15 ` David Henderson
2011-06-30 15:43 ` David Henderson
2011-06-30 17:01 ` Lu Guanqun
2011-07-01 6:41 ` Takashi Iwai
2011-07-11 14:26 ` David Henderson
2011-07-11 14:43 ` Takashi Iwai
2011-07-11 15:05 ` David Henderson
2011-07-11 15:12 ` Takashi Iwai
2011-07-11 15:13 ` David Henderson
2011-07-11 15:17 ` Takashi Iwai
2011-07-11 15:25 ` David Henderson
2011-07-11 15:52 ` Takashi Iwai
2011-07-12 13:05 ` David Henderson
2011-07-12 13:13 ` Takashi Iwai
2011-07-12 13:30 ` David Henderson
2011-07-13 13:14 ` David Henderson
2011-07-13 14:08 ` Takashi Iwai
2011-07-13 14:25 ` David Henderson
2011-07-13 14:31 ` Takashi Iwai
2011-07-22 18:23 ` David Henderson
2011-07-22 19:24 ` Takashi Iwai
2011-06-30 17:34 ` alex dot baldacchino dot alsasub at gmail dot com
2011-06-30 19:02 ` David Henderson
2011-07-01 0:48 ` alex dot baldacchino dot alsasub at gmail dot com
2011-07-11 14:32 ` David Henderson
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.