additional problem

additional problem

[David Henderson]

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

Re: additional problem

[David Henderson]

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

Re: additional problem

[David Henderson]

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

Re: additional problem

[Lu Guanqun]

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

Re: additional problem

[Takashi Iwai]

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

Re: additional problem

[David Henderson]

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

Re: additional problem

[Takashi Iwai]

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

Re: additional problem

[David Henderson]

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

Re: additional problem

[Takashi Iwai]

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

Re: additional problem

[David Henderson]

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

Re: additional problem

[Takashi Iwai]

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

Re: additional problem

[David Henderson]

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

Re: additional problem

[Takashi Iwai]

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

Re: additional problem

[David Henderson]

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

Re: additional problem

[Takashi Iwai]

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

Re: additional problem

[David Henderson]

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

Re: additional problem

[David Henderson]

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

Re: additional problem

[Takashi Iwai]

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

Re: additional problem

[David Henderson]

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

Re: additional problem

[Takashi Iwai]

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

Re: additional problem

[David Henderson]

[-- 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 --]

Re: additional problem

[Takashi Iwai]

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

Re: additional problem

[alex dot baldacchino dot alsasub at gmail dot com]

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

Re: additional problem

[David Henderson]

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

Re: additional problem

[alex dot baldacchino dot alsasub at gmail dot com]

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

Re: additional problem

[David Henderson]

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