Re: [Alsa-user] First post
Hi, From: David Henderson dhender...@digital-pipe.com Subject: Re: [Alsa-user] First post Date: Sun, 19 Jun 2011 15:28:48 -0400 Thanks for the reply Pierre. I checked into the blfs book, but it merely says these five chapters will cover alsa and then gives you a basic type configure make. This is obviously not going to answer the questions below. :) Any other thoughts? Dave On 06/19/2011 11:22 PM, Pierre Lorenzon wrote: Hi, It looks like to me such questions are well answered in the blfs book. I personnaly think that the latter is a very good tool to build his own custom distro. Bests Pierre From: David Hendersondhender...@digital-pipe.com Subject: [Alsa-user] First post Date: Sun, 19 Jun 2011 14:41:08 -0400 Hi everyone! I'm currently expanding my knowledge of GNU/Linux to include building packages from scratch towards an overall goal of a custom distro. So far, I have a nice base for a command line OS, but want to expand into the multimedia aspect. Alsa was my first (only?) choice for the audio portion, but I'm running into problems. The alsa site is somewhat overwhelming to newbies and is easy to get lost. I have a few questions below from which I hope I can find help. All contributions are greatly appreciated. :) Thanks, Dave 1) Currently I have downloaded alsa-driver, alsa-lib, and alsa-utils packages. Is there an order in which these packages need to be compiled and installed? This question is answered by the blfs book. First alsa-lib and after alsa-utils. 2) I'm currently running the relatively new Linux kernel 2.6.33 so do I need the alsa-driver package? No ! I am running a 2.6.32 kernel and never installed alsa-driver. Anyway if the sound system is something very exotic it might be necessary ... 3) I've been able to successfully compile the alsa-lib package and install it in the custom distro. When I try to compile the alsa-utils package, I constantly get the error: checking for libasound headers version= 1.0.16... not present. configure: error: Sufficiently new version of libasound not found. I'm actually using an existing Kubuntu installation to build the packages for my custom distro. As a result, after I compiled the newer alsa-lib, I didn't install the package into the Kubuntu OS, but rather a staging directory (/opt/staging/alsa). I'm sure the reason this is failing is because it's probably looking for /usr/lib/... or some other default location. How do I tell the configure script for the alsa-utils to look in the staging directory for the header files it needs? Humm ! I don't really understand this method. In my opinion if you want to have a custom distro you first install a basic systme on a partition or in a directory. Once the basic system is installed (more or less the content of the lfs book) you simply chroot to this new system to install the rest of the stuff. Following this scheme there will be no problem. I did it many times ! It leads me to a more global question : you say you want to build a custom distro but do you have some kind of documentation to do that ? If you plan to do that on your own, it's a big deal ! Anyway I'll suggest you to have a look at the lfs book. It might be that the installation schedule suggested by the lfs team is not suitable for you but in my opinion it is better to check this point before reinventing the weel as we say in french ! Bests Pierre -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] First post
From: James Shatto wwwshad...@gmail.com Subject: Re: [Alsa-user] First post Date: Sun, 19 Jun 2011 15:36:59 -0500 A) If you want to overwrite your existing distro's versions, you probably want the --prefix=/usr option on your ./configure commands. If not, be sure to change your $PATH to look at /usr/local FIRST. B) Compile alsa-lib first, alsa-driver second. Most compile options only need --prefix=/usr if you want to override the default of /usr/local. But alsa-driver requires extra parms depending on what you want. Some packages are only tool sets, so make -f Makefile? And use them from where you made them, or copy/move them to more common $PATH's. C) You might have versioning conflicts depending on what you're trying to mix and match. libc and other things might not work well together unless you're running the latest and greatest of every component. And even that is problematic some of the time. D) unless you have a lot of time to waste, or just need the learning, I'd recommend going with existing distros. There's enough of them that one might suit your current needs. www.distrowatch.com I suggested something intermediary : lfs or gentoo which are easily customizable. Pierre HTH, - James On 6/19/11, David Henderson dhender...@digital-pipe.com wrote: Thanks for the reply Pierre. I checked into the blfs book, but it merely says these five chapters will cover alsa and then gives you a basic type configure make. This is obviously not going to answer the questions below. :) Any other thoughts? Dave On 06/19/2011 11:22 PM, Pierre Lorenzon wrote: Hi, It looks like to me such questions are well answered in the blfs book. I personnaly think that the latter is a very good tool to build his own custom distro. Bests Pierre From: David Hendersondhender...@digital-pipe.com Subject: [Alsa-user] First post Date: Sun, 19 Jun 2011 14:41:08 -0400 Hi everyone! I'm currently expanding my knowledge of GNU/Linux to include building packages from scratch towards an overall goal of a custom distro. So far, I have a nice base for a command line OS, but want to expand into the multimedia aspect. Alsa was my first (only?) choice for the audio portion, but I'm running into problems. The alsa site is somewhat overwhelming to newbies and is easy to get lost. I have a few questions below from which I hope I can find help. All contributions are greatly appreciated. :) Thanks, Dave 1) Currently I have downloaded alsa-driver, alsa-lib, and alsa-utils packages. Is there an order in which these packages need to be compiled and installed? 2) I'm currently running the relatively new Linux kernel 2.6.33 so do I need the alsa-driver package? 3) I've been able to successfully compile the alsa-lib package and install it in the custom distro. When I try to compile the alsa-utils package, I constantly get the error: checking for libasound headers version= 1.0.16... not present. configure: error: Sufficiently new version of libasound not found. I'm actually using an existing Kubuntu installation to build the packages for my custom distro. As a result, after I compiled the newer alsa-lib, I didn't install the package into the Kubuntu OS, but rather a staging directory (/opt/staging/alsa). I'm sure the reason this is failing is because it's probably looking for /usr/lib/... or some other default location. How do I tell the configure script for the alsa-utils to look in the staging directory for the header files it needs? -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net
Re: [Alsa-user] First post
... or Sorcerer. James, you need to use the new system for compiling, not some other one. And how do you install applications on your custom system? By .deb packages?!?! Come on, this is not a custom system! This is exactly what Pierre said: reinventing the wheel. Like Ubuntu for Debian - who needs a copy when you have the original *for free*!!! You might be better using an already established distro, or if you want to go a little more in-deep, you might want to try a source based distro: that will definitely help you better understand the linux environment than what you are trying to do. There are already known dependencies that these distros will give you the choice to compile in or not. But doing that all by yourself is really an misuse of resources. If you do have that much free time, why don't you continue an already existing project? Join a project and ask for work: there will be so much interesting things you could do that will be over your head in less than a week after joining any open source project. Just ask! Keep up the good work! Work together! On 20.06.2011 18:55, Pierre Lorenzon wrote: From: James Shattowwwshad...@gmail.com Subject: Re: [Alsa-user] First post Date: Sun, 19 Jun 2011 15:36:59 -0500 A) If you want to overwrite your existing distro's versions, you probably want the --prefix=/usr option on your ./configure commands. If not, be sure to change your $PATH to look at /usr/local FIRST. B) Compile alsa-lib first, alsa-driver second. Most compile options only need --prefix=/usr if you want to override the default of /usr/local. But alsa-driver requires extra parms depending on what you want. Some packages are only tool sets, so make -f Makefile? And use them from where you made them, or copy/move them to more common $PATH's. C) You might have versioning conflicts depending on what you're trying to mix and match. libc and other things might not work well together unless you're running the latest and greatest of every component. And even that is problematic some of the time. D) unless you have a lot of time to waste, or just need the learning, I'd recommend going with existing distros. There's enough of them that one might suit your current needs. www.distrowatch.com I suggested something intermediary : lfs or gentoo which are easily customizable. Pierre HTH, - James On 6/19/11, David Hendersondhender...@digital-pipe.com wrote: Thanks for the reply Pierre. I checked into the blfs book, but it merely says these five chapters will cover alsa and then gives you a basic type configure make. This is obviously not going to answer the questions below. :) Any other thoughts? Dave On 06/19/2011 11:22 PM, Pierre Lorenzon wrote: Hi, It looks like to me such questions are well answered in the blfs book. I personnaly think that the latter is a very good tool to build his own custom distro. Bests Pierre From: David Hendersondhender...@digital-pipe.com Subject: [Alsa-user] First post Date: Sun, 19 Jun 2011 14:41:08 -0400 Hi everyone! I'm currently expanding my knowledge of GNU/Linux to include building packages from scratch towards an overall goal of a custom distro. So far, I have a nice base for a command line OS, but want to expand into the multimedia aspect. Alsa was my first (only?) choice for the audio portion, but I'm running into problems. The alsa site is somewhat overwhelming to newbies and is easy to get lost. I have a few questions below from which I hope I can find help. All contributions are greatly appreciated. :) Thanks, Dave 1) Currently I have downloaded alsa-driver, alsa-lib, and alsa-utils packages. Is there an order in which these packages need to be compiled and installed? 2) I'm currently running the relatively new Linux kernel 2.6.33 so do I need the alsa-driver package? 3) I've been able to successfully compile the alsa-lib package and install it in the custom distro. When I try to compile the alsa-utils package, I constantly get the error: checking for libasound headers version= 1.0.16... not present. configure: error: Sufficiently new version of libasound not found. I'm actually using an existing Kubuntu installation to build the packages for my custom distro. As a result, after I compiled the newer alsa-lib, I didn't install the package into the Kubuntu OS, but rather a staging directory (/opt/staging/alsa). I'm sure the reason this is failing is because it's probably looking for /usr/lib/... or some other default location. How do I tell the configure script for the alsa-utils to look in the staging directory for the header files it needs? -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking.
[Alsa-user] pci device ordering
hi all, i have a machine with two pci devices of the same type. how can i ensure persistent device indices? the wiki [1] mentions a way for a way using vid/pid, but for pci devices it suggests to write a udev rule. [2] has an example, but it only describes how to set up the device names in /dev/snd. but how do i bind a specific device to an alsa device index (hw:X)? thanks, tim [1] http://alsa.opensrc.org/MultipleCards#How_to_choose_a_particular_order_for_multiple_installed_cards [2] http://alsa.opensrc.org/Udev -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] First post
Thanks again for the continued help James. I knew '--prefix' was a 'configure' option, but thought one would use it when permanently installing the software to a non-standard directory on the system. Since this software is being compiled on a temp system and installing to a staging directory, wouldn't the 'DESTDIR' be a better option to use while compiling the software so it can be packaged and installed on the custom distro? Thanks for the tips on the kernel headers and configure parameters. :) Dave On 06/19/2011 07:06 PM, James Shatto wrote: --prefix is a ./configure option. If you're going to apply the new alsa to an existing distro kernel and not a custom from source one. You'll likely need to install the kernel-headers package for that kernel and distro. And may need to manually move the old version of alsa (or remove). Plus that whole depmod thing. $ dpkg -l '*kernel*headers*' Which resolves to linux-kernel-headers in debian. Which is a psuedo package for: linux-libc-dev 2.6.26-26lenny3 and of course 2.6.26-26lenny3 resolves to linux-tree-2.6.26lenny3 so: # apt-get install linux-libc-dev linux-tree-2.6.26-26lenny3 (in debian 5.0 / lenny) If it's a custom one, just don't make clean after making the kernel. It should reside in /lib/modules/`uname -r`/build/ or something like that. BITD, this would just be a symlink to/from /usr/src/linux and was what early alsa assumed by default. Depending on what multimedia features you need. You might want --with-sequencer=yes and --with-oss=yes and a --driver=your card options on your alsa-driver compile. Without those =no might be assumed. And you might compile ALL drivers which could take a really long time. Less so these days, but BITD, the better part of a day it seemed. It really depends on what you want interacting with your sound card. Timidity and other synth like software requires the --with-sequencer=yes if your card doesn't have native midi abilities (most don't these days). And various pulse-audio and browsers and other things that just need --with-oss=yes or things might not work as expected, if at all. Little things that you'll find out one way or another as you learn your way around. HTH, - James On 6/19/11, David Hendersondhender...@digital-pipe.com wrote: Hi James, thanks for your help too. :) I'll provide replies in the same fashion given. A) I don't want to overwrite the Kubuntu installation files as I'm compiling this version of alsa for my own distro. I would prefer to use Kubuntu's pre-packaged software within itself. So since the compiled version of alsa will be going into /opt/staging/alsa, should I include --prefix=/opt/staging/alsa as the parameter to configure? B) I'll assume at this point, that no matter what version of the Linux kernel is being used, it's still required to install the alsa-driver package. That being said, I'm going to run into the same problem as A above since the version of Kubuntu I'm using to build the custom distro isn't using the same kernel version. So what configure option do I have to pass in order for alsa to see the source code of the custom distro's kernel version? C) So far, so good, but I'll keep that in mind. :) D) Thanks for the URL, but this is a project that I've wanted to do for the last 5-7 years and now I have the ability to do so. Not only that, but knowing details at this level of building an OS can also help with my job - so I get a two fold benefit. :) Otherwise, I'd definitely follow your advice! lol Thanks again for your help, I look forward to hearing back from you. Dave On 06/19/2011 04:36 PM, James Shatto wrote: A) If you want to overwrite your existing distro's versions, you probably want the --prefix=/usr option on your ./configure commands. If not, be sure to change your $PATH to look at /usr/local FIRST. B) Compile alsa-lib first, alsa-driver second. Most compile options only need --prefix=/usr if you want to override the default of /usr/local. But alsa-driver requires extra parms depending on what you want. Some packages are only tool sets, so make -f Makefile? And use them from where you made them, or copy/move them to more common $PATH's. C) You might have versioning conflicts depending on what you're trying to mix and match. libc and other things might not work well together unless you're running the latest and greatest of every component. And even that is problematic some of the time. D) unless you have a lot of time to waste, or just need the learning, I'd recommend going with existing distros. There's enough of them that one might suit your current needs. www.distrowatch.com HTH, - James On 6/19/11, David Hendersondhender...@digital-pipe.com wrote: Thanks for the reply Pierre. I checked into the blfs book, but it merely says these five chapters will cover alsa and then gives you a basic type configure make. This is obviously not
Re: [Alsa-user] First post
Well many source packages default to /usr/local/ Many distros default to /usr/ And the distros IGNORE /usr/local/ unless otherwise told. It's not a compile thing, it's a runtime thing. Of course you could always run things with the full paths /usr/local/bin/alsamixer and such. But if you add the location in $PATH, it'll find it. But if you use the default /usr/local/ it might look for and load the distros version from /usr/ first. So I generally overwrite the distro's versions. i.e. make install and --prefix=/usr. Versus building debs and installing it that way which is the preferred way to do thing. But mainly because I can never recall the fakeroot debian/binary stuff to make debs off the top of my head. And I don't always have networking setup to google it at the stage that I'm installing alsa. But I don't do enough from source stuff to really consider my setup a different distro. Just customized per say. If only for the optimization of not having to look through 1,000 drivers for the 1 that is actually used. And media players with CPU specific optimizations are always nice. As a side note, alsa is in the 2.6 kernel tree. Are we on 2.8 yet? So if you compile a recent kernel, you automagically get a recent alsa version with it. Or if your distro offers a recent kernel. It's done for you. No need to re-invent the wheel as previously said. But sometimes your distro doesn't package things in a way that you want to use them. i.e. Timidity with sequencer support. Jackd with sequencer support. Alsa with OSS emulation. And other fine tuning type needs. Or your distro is on such an ancient kernel, that stuff just doesn't work at all given the lack of age of your hardware versus the copious amounts of age in your kernel version. - James On 6/20/11, David Henderson dhender...@digital-pipe.com wrote: Thanks again for the continued help James. I knew '--prefix' was a 'configure' option, but thought one would use it when permanently installing the software to a non-standard directory on the system. Since this software is being compiled on a temp system and installing to a staging directory, wouldn't the 'DESTDIR' be a better option to use while compiling the software so it can be packaged and installed on the custom distro? Thanks for the tips on the kernel headers and configure parameters. :) Dave On 06/19/2011 07:06 PM, James Shatto wrote: --prefix is a ./configure option. If you're going to apply the new alsa to an existing distro kernel and not a custom from source one. You'll likely need to install the kernel-headers package for that kernel and distro. And may need to manually move the old version of alsa (or remove). Plus that whole depmod thing. $ dpkg -l '*kernel*headers*' Which resolves to linux-kernel-headers in debian. Which is a psuedo package for: linux-libc-dev 2.6.26-26lenny3 and of course 2.6.26-26lenny3 resolves to linux-tree-2.6.26lenny3 so: # apt-get install linux-libc-dev linux-tree-2.6.26-26lenny3 (in debian 5.0 / lenny) If it's a custom one, just don't make clean after making the kernel. It should reside in /lib/modules/`uname -r`/build/ or something like that. BITD, this would just be a symlink to/from /usr/src/linux and was what early alsa assumed by default. Depending on what multimedia features you need. You might want --with-sequencer=yes and --with-oss=yes and a --driver=your card options on your alsa-driver compile. Without those =no might be assumed. And you might compile ALL drivers which could take a really long time. Less so these days, but BITD, the better part of a day it seemed. It really depends on what you want interacting with your sound card. Timidity and other synth like software requires the --with-sequencer=yes if your card doesn't have native midi abilities (most don't these days). And various pulse-audio and browsers and other things that just need --with-oss=yes or things might not work as expected, if at all. Little things that you'll find out one way or another as you learn your way around. HTH, - James On 6/19/11, David Hendersondhender...@digital-pipe.com wrote: Hi James, thanks for your help too. :) I'll provide replies in the same fashion given. A) I don't want to overwrite the Kubuntu installation files as I'm compiling this version of alsa for my own distro. I would prefer to use Kubuntu's pre-packaged software within itself. So since the compiled version of alsa will be going into /opt/staging/alsa, should I include --prefix=/opt/staging/alsa as the parameter to configure? B) I'll assume at this point, that no matter what version of the Linux kernel is being used, it's still required to install the alsa-driver package. That being said, I'm going to run into the same problem as A above since the version of Kubuntu I'm using to build the custom distro isn't using the same kernel version. So what configure option do I have to pass in order for
Re: [Alsa-user] First post
Hi Ady, thanks for contributing to the conversation. :) I have a couple of questions based on your response below... Why do I need to use the new system for compiling? Isn't there normally 'configure' and 'make' options that allow for compiling on one system so the software can be packaged for installation on another system (e.g. DESTDIR)? The custom distro doesn't use .deb packages or any other existing package manager. I think James was referring to obtaining certain packages in Kubuntu (which is .deb based) so the alsa packages could be compiled on it and migrated over to the custom distro. I appreciate you guys steering me in the direction of using existing distro's, but there are several reasons to roll my own. And the reasons I don't want to join an existing project is because 1) there isn't another distro like the one I'm building as I've looked 2) instead of having to debate/argue with existing members over implementing changes, I can just re-route the time and headache into figuring out how to build my own. lol Some may consider this a misuse of resources, but if nobody was adventurous enough to break away from the norm, we've never have innovation. :) Again, I appreciate you guys trying to steer me in the direction most should go, but it isn't the route for everyone. :) Dave On 06/20/2011 04:06 AM, Ady Deac wrote: ... or Sorcerer. James, you need to use the new system for compiling, not some other one. And how do you install applications on your custom system? By .deb packages?!?! Come on, this is not a custom system! This is exactly what Pierre said: reinventing the wheel. Like Ubuntu for Debian - who needs a copy when you have the original *for free*!!! You might be better using an already established distro, or if you want to go a little more in-deep, you might want to try a source based distro: that will definitely help you better understand the linux environment than what you are trying to do. There are already known dependencies that these distros will give you the choice to compile in or not. But doing that all by yourself is really an misuse of resources. If you do have that much free time, why don't you continue an already existing project? Join a project and ask for work: there will be so much interesting things you could do that will be over your head in less than a week after joining any open source project. Just ask! Keep up the good work! Work together! On 20.06.2011 18:55, Pierre Lorenzon wrote: From: James Shattowwwshad...@gmail.com Subject: Re: [Alsa-user] First post Date: Sun, 19 Jun 2011 15:36:59 -0500 A) If you want to overwrite your existing distro's versions, you probably want the --prefix=/usr option on your ./configure commands. If not, be sure to change your $PATH to look at /usr/local FIRST. B) Compile alsa-lib first, alsa-driver second. Most compile options only need --prefix=/usr if you want to override the default of /usr/local. But alsa-driver requires extra parms depending on what you want. Some packages are only tool sets, so make -f Makefile? And use them from where you made them, or copy/move them to more common $PATH's. C) You might have versioning conflicts depending on what you're trying to mix and match. libc and other things might not work well together unless you're running the latest and greatest of every component. And even that is problematic some of the time. D) unless you have a lot of time to waste, or just need the learning, I'd recommend going with existing distros. There's enough of them that one might suit your current needs. www.distrowatch.com I suggested something intermediary : lfs or gentoo which are easily customizable. Pierre HTH, - James On 6/19/11, David Hendersondhender...@digital-pipe.com wrote: Thanks for the reply Pierre. I checked into the blfs book, but it merely says these five chapters will cover alsa and then gives you a basic type configure make. This is obviously not going to answer the questions below. :) Any other thoughts? Dave On 06/19/2011 11:22 PM, Pierre Lorenzon wrote: Hi, It looks like to me such questions are well answered in the blfs book. I personnaly think that the latter is a very good tool to build his own custom distro. Bests Pierre From: David Hendersondhender...@digital-pipe.com Subject: [Alsa-user] First post Date: Sun, 19 Jun 2011 14:41:08 -0400 Hi everyone! I'm currently expanding my knowledge of GNU/Linux to include building packages from scratch towards an overall goal of a custom distro. So far, I have a nice base for a command line OS, but want to expand into the multimedia aspect. Alsa was my first (only?) choice for the audio portion, but I'm running into problems. The alsa site is somewhat overwhelming to newbies and is easy to get lost. I have a few questions below from which I hope I can find help. All contributions are greatly appreciated. :)
Re: [Alsa-user] First post
If you're really into going it on your own. There's gentoo, and there's LFS aka linux from scratch. Both of which impose a lot of source compilation. The inherent problem with sources is that you run into maintenance issues. i.e. If you use the same install for a long enough time, it'll eventually become unusable due to remnants of old versions and not enough hours in a lifetime to figure out what/where those are and manually correct. Ultimately you'll be doing fresh installs long before your hardware's expiration date. Not that I don't do regular installs myself. But I swap out hard drives every two years to be pro-active against that type of failure. And I do a lot of media editing, so I probably abuse my drives more than most. A distro is just a good ideal. There's configuration files that you really can't generate by hand without a pretty hefty understanding of what you are doing. Distros have done all this legwork for you and provide you with a sane default configuration file where you just need to uncomment a line to enable something or comment it to disable it. Lots of sanity saving things in a distro that you'll be scouring sources to figure out on your own in LFS land. And probably installing a distro anyway to cp their config. There's a lot to learn. But really you don't need to learn that stuff. There's no bread and butter / money in it. Sure you'll have a greater understanding. And should some do or die worst case scenario happen you'll know how to resolve it, where most other folks wont know where to begin. But really most IT jobs these days are installing and uninstalling and configuration gigs. We don't need to write a word processor, as one (several actually) already exist. And some of them aren't too shabby. As far as build systems. The configure + make + make install is the OLD way. Not all sources use that one. There's scons, mercurial, and various *make incarnations. And of course distro specific ways that are compatible with their package manager(s). Plus the typical development role of 1001 ways to do one thing. Fortunately alsa is still a bit old school. Or unfortunately depending on your POV. - James -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] First post
Currently there is no alsa installed in the custom distro, so there won't be any overwritting. :) I just don't want to install the version of alsa I'm compiling into my running version of Kubuntu because I'd rather use software from it's package repositories to avoid the headaches mentioned by everyone. :) There should be no mixing of the software I'm compiling with Kubuntu other than what gets installed for packaging in the staging directory (/opt/staging/alsa). There are no .deb packages being used or created with the custom distro. Currently whatever is being compiled in the staging directory (/opt/staging/...) simply gets tar'ed and moved to the root of the custom distro (e.g. /opt/staging/alsa/bin on Kubuntu becomes /bin on custom distro). I'm just using Kubuntu as the OS to compile and build on. The more I read the replies, I'm thinking that everyone thinks I'm trying to modify a Kubuntu installation which is not the case. The custom distro uses busybox, resides in the RAM, and contains several other large differences. This is nowhere near me taking an existing distro and installing some (additional) software. :) It's being built from the ground up using my Kubuntu installation as the OS to build the packages. Once I'm further along, I'll begin using the custom distro to build the packages, but for right now, it's much easier to use Kubuntu due to the simplicity of using their software repository to satisfy any compile time requirements. Since I'm not overwritting the alsa installed on the Kubuntu system, I don't think there's a need for --prefix. I think I just need to be able to have the 'configure' script look for the compiled alsa-lib package in the /opt/staging/alsa directory while compiling only. Using --prefix will make the software always look in the /opt/staging/alsa directory on the custom distro - which isn't the real location as there isn't an /opt/staging/... directory. Regarding the kernel, since I'm using a relatively recent kernel (2.6.33), should I just be compiling the alsa-utils package then and not worry about alsa-lib or alsa-driver? Which alsa package(s) are included within the kernel source? Thanks, Dave On Mon, Jun 20, 2011 at 9:28 AM, James Shatto wwwshad...@gmail.com wrote: Well many source packages default to /usr/local/ Many distros default to /usr/ And the distros IGNORE /usr/local/ unless otherwise told. It's not a compile thing, it's a runtime thing. Of course you could always run things with the full paths /usr/local/bin/alsamixer and such. But if you add the location in $PATH, it'll find it. But if you use the default /usr/local/ it might look for and load the distros version from /usr/ first. So I generally overwrite the distro's versions. i.e. make install and --prefix=/usr. Versus building debs and installing it that way which is the preferred way to do thing. But mainly because I can never recall the fakeroot debian/binary stuff to make debs off the top of my head. And I don't always have networking setup to google it at the stage that I'm installing alsa. But I don't do enough from source stuff to really consider my setup a different distro. Just customized per say. If only for the optimization of not having to look through 1,000 drivers for the 1 that is actually used. And media players with CPU specific optimizations are always nice. As a side note, alsa is in the 2.6 kernel tree. Are we on 2.8 yet? So if you compile a recent kernel, you automagically get a recent alsa version with it. Or if your distro offers a recent kernel. It's done for you. No need to re-invent the wheel as previously said. But sometimes your distro doesn't package things in a way that you want to use them. i.e. Timidity with sequencer support. Jackd with sequencer support. Alsa with OSS emulation. And other fine tuning type needs. Or your distro is on such an ancient kernel, that stuff just doesn't work at all given the lack of age of your hardware versus the copious amounts of age in your kernel version. - James On 6/20/11, David Henderson dhender...@digital-pipe.com wrote: Thanks again for the continued help James. I knew '--prefix' was a 'configure' option, but thought one would use it when permanently installing the software to a non-standard directory on the system. Since this software is being compiled on a temp system and installing to a staging directory, wouldn't the 'DESTDIR' be a better option to use while compiling the software so it can be packaged and installed on the custom distro? Thanks for the tips on the kernel headers and configure parameters. :) Dave On 06/19/2011 07:06 PM, James Shatto wrote: --prefix is a ./configure option. If you're going to apply the new alsa to an existing distro kernel and not a custom from source one. You'll likely need to install the kernel-headers package for that kernel and distro. And may need to manually move the old
Re: [Alsa-user] Alsa-user Digest, Vol 62, Issue 10 (Action Required)
Dear sender, You will not receive any more courtesy notices from our members for two days. Messages you have sent will remain in a lower priority mailbox for our member to review at their leisure. Future messages will be more likely to be viewed if you are on our member's priority Guest List. Thank you, cristiano.barb...@gmail.com Powered by Boxbe -- End Email Overload Visit http://www.boxbe.com/how-it-works?tc=8456873545_1146629074 Reporting-MTA: dns; boxbe.com Remote-MTA: dns; yahoo.com Action: failed Arrival-Date: Mon, 20 Jun 2011 08:22:44 -0700 (PDT) Final-Recipient: rfc822; cristiano.barbaro@gmail.com Diagnostic-Code: X-Boxbe-Notice; Sender not pre-approved. Follow instructions in above notice Status: 4.7.0 ---BeginMessage--- ---End Message--- -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
[Alsa-user] plughw versus hw
Hello, I can imagine that this is a FAQ, but I could not find a clear answer : which precise difference(s) distinguish(es) plughw and hw from each other ? Does plughw apply sound processing that hw does not ? Thanks in advance for any explanation on this subject. Pierre -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] First post
On 06/20/2011 11:52 AM, Pierre Lorenzon wrote: Hi, From: David Hendersondhender...@digital-pipe.com Subject: Re: [Alsa-user] First post Date: Sun, 19 Jun 2011 15:28:48 -0400 Thanks for the reply Pierre. I checked into the blfs book, but it merely says these five chapters will cover alsa and then gives you a basic type configure make. This is obviously not going to answer the questions below. :) Any other thoughts? Dave On 06/19/2011 11:22 PM, Pierre Lorenzon wrote: Hi, It looks like to me such questions are well answered in the blfs book. I personnaly think that the latter is a very good tool to build his own custom distro. Bests Pierre From: David Hendersondhender...@digital-pipe.com Subject: [Alsa-user] First post Date: Sun, 19 Jun 2011 14:41:08 -0400 Hi everyone! I'm currently expanding my knowledge of GNU/Linux to include building packages from scratch towards an overall goal of a custom distro. So far, I have a nice base for a command line OS, but want to expand into the multimedia aspect. Alsa was my first (only?) choice for the audio portion, but I'm running into problems. The alsa site is somewhat overwhelming to newbies and is easy to get lost. I have a few questions below from which I hope I can find help. All contributions are greatly appreciated. :) Thanks, Dave 1) Currently I have downloaded alsa-driver, alsa-lib, and alsa-utils packages. Is there an order in which these packages need to be compiled and installed? This question is answered by the blfs book. First alsa-lib and after alsa-utils. 2) I'm currently running the relatively new Linux kernel 2.6.33 so do I need the alsa-driver package? No ! I am running a 2.6.32 kernel and never installed alsa-driver. Anyway if the sound system is something very exotic it might be necessary ... Great one less thing to compile! :) 3) I've been able to successfully compile the alsa-lib package and install it in the custom distro. When I try to compile the alsa-utils package, I constantly get the error: checking for libasound headers version= 1.0.16... not present. configure: error: Sufficiently new version of libasound not found. I'm actually using an existing Kubuntu installation to build the packages for my custom distro. As a result, after I compiled the newer alsa-lib, I didn't install the package into the Kubuntu OS, but rather a staging directory (/opt/staging/alsa). I'm sure the reason this is failing is because it's probably looking for /usr/lib/... or some other default location. How do I tell the configure script for the alsa-utils to look in the staging directory for the header files it needs? Humm ! I don't really understand this method. In my opinion if you want to have a custom distro you first install a basic systme on a partition or in a directory. Once the basic system is installed (more or less the content of the lfs book) you simply chroot to this new system to install the rest of the stuff. Following this scheme there will be no problem. I did it many times ! It leads me to a more global question : you say you want to build a custom distro but do you have some kind of documentation to do that ? If you plan to do that on your own, it's a big deal ! Anyway I'll suggest you to have a look at the lfs book. It might be that the installation schedule suggested by the lfs team is not suitable for you but in my opinion it is better to check this point before reinventing the weel as we say in french ! Bests Pierre I guess the best way to describe what I'm trying to accomplish would be to look at it from a package maintainers perspective. They have to compile the source code into a staging directory so they can package the software. If they just ran the normal configure make make install, how would they know what files to include in the software package as they get spread through the FS? There has to be a staging directory that contains everything in isolation so that the package maintainer doesn't have to do so much overhead just to create a package, but when the package is installed, it works correctly (hence using DESTDIR and not --prefix). The problem I'm having, as stated, is that I think alsa is looking for header files or whatever under normal installation directories (e.g. /usr/... or /usr/local/...), but I need it to look under the staging directory (/opt/staging/alsa) since that's where the other matching compiled packages of alsa reside. Any thoughts to accomplish this? In other words, what are the compile parameters a package maintainer includes to compile alsa? Thanks, Dave -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track
Re: [Alsa-user] plughw versus hw
Hi Pierre Habraken! On 2011.06.20 at 19:32:28 +0200, Pierre Habraken wrote next: I can imagine that this is a FAQ, but I could not find a clear answer : which precise difference(s) distinguish(es) plughw and hw from each other ? Does plughw apply sound processing that hw does not ? plughw *might* apply simple sound processing if needed, mostly channels conversion and rate conversion if required. It doesn't have to apply processing. hw doesn't support such processing only works when operating strictly in mode that audio card support. If you have device that supports only 2 channel, 16 bit 48000 mode then hw device won't be able to playback 2/16/44100 stream, or mono stream for example; you'll get an error when you try. But plughw will accept such streams and do the conversion. However, if you use plughw and output 2/16/48000 stream then no conversion is needed and most likely plughw won't be doing any processing. Note that using both hw and plughw can lead to specific problems, so it's best to use default device unless you have very specific requirements. -- Vladimir -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] First post
Ummm. I'm not sure if I follow you. $ make will build the objects and stuff in the current path of your source tree. $ make install copies the executables to the system usable locations. /usr/bin/ /lib/modules/. /usr/share/doc/. (which is why you need to be root in a lot of cases to run make install, but not to run make) A package maintainer will likely use stuff like what's in debian/rules debian/binary and such to build a package manager package, instead of using make install to place the important components (results) where they need to be. A package manager package lets you keep track of what got installed and where and the package provides additional features useful for long term maintenance and/or large scale deployment. If you want to build a package (i.e. .deb) you'd use those tools for that to do that. Otherwise you have to at least mimic make install. Which is a bit futile IMO, given that you could just run make install. i.e. how exactly would you create your tarball? From a diff of an entire backup before and after make install? By doing everything done by make install manually? That's fine for relatively small things like alsa. But for X, KDE, ???, and other more bulky entities. You'd need a couple lifetimes of spare time to re-invent make install. And scons install and and ... and ... Also bear in mind that if you're building something on a system other than the one where it will be deployed. You will run into some version compatibility issues. Just a minor difference in the API between version 1.0.24 and 1.0.25 could make things unusable. And as previously mentioned, alsa comes with the 2.6 kernel, so you'll have an existing version already in place that you will need to deal with, one way or another. When there's multiple versions of things, at runtime things like to load in alphabetical order or ascii order at least. Which generally means the that OLDer version takes priority. So even if you install your newer version, it's probably going to be ignored unless you remove or replace the older version. The manual approach to dependency hell I guess, of sorts. Lots of little things that will keep you from succeeding. It's probably time better spent learning an existing package management system IMO. Than to create your own. Especially if you're on your own and not part of team. But it's almost all open source so if you can read the source, everything that you need to know is there in one form or another. - James On 6/20/11, David Henderson dhender...@digital-pipe.com wrote: On 06/20/2011 11:52 AM, Pierre Lorenzon wrote: Hi, From: David Hendersondhender...@digital-pipe.com Subject: Re: [Alsa-user] First post Date: Sun, 19 Jun 2011 15:28:48 -0400 Thanks for the reply Pierre. I checked into the blfs book, but it merely says these five chapters will cover alsa and then gives you a basic type configure make. This is obviously not going to answer the questions below. :) Any other thoughts? Dave On 06/19/2011 11:22 PM, Pierre Lorenzon wrote: Hi, It looks like to me such questions are well answered in the blfs book. I personnaly think that the latter is a very good tool to build his own custom distro. Bests Pierre From: David Hendersondhender...@digital-pipe.com Subject: [Alsa-user] First post Date: Sun, 19 Jun 2011 14:41:08 -0400 Hi everyone! I'm currently expanding my knowledge of GNU/Linux to include building packages from scratch towards an overall goal of a custom distro. So far, I have a nice base for a command line OS, but want to expand into the multimedia aspect. Alsa was my first (only?) choice for the audio portion, but I'm running into problems. The alsa site is somewhat overwhelming to newbies and is easy to get lost. I have a few questions below from which I hope I can find help. All contributions are greatly appreciated. :) Thanks, Dave 1) Currently I have downloaded alsa-driver, alsa-lib, and alsa-utils packages. Is there an order in which these packages need to be compiled and installed? This question is answered by the blfs book. First alsa-lib and after alsa-utils. 2) I'm currently running the relatively new Linux kernel 2.6.33 so do I need the alsa-driver package? No ! I am running a 2.6.32 kernel and never installed alsa-driver. Anyway if the sound system is something very exotic it might be necessary ... Great one less thing to compile! :) 3) I've been able to successfully compile the alsa-lib package and install it in the custom distro. When I try to compile the alsa-utils package, I constantly get the error: checking for libasound headers version= 1.0.16... not present. configure: error: Sufficiently new version of libasound not found. I'm actually using an existing Kubuntu installation to build the packages for my custom distro. As a result, after I compiled the newer alsa-lib, I didn't install the package into
Re: [Alsa-user] Which pci-e card?
Another question i have decided to buy magma box 7 pci. Are you sure debian 6 always load the magma pci slots in the same order? Otherwise you can understand that for me is an insurmountable problem Thanks Il giorno 16/giu/2011 18.42, li...@lazygranch.com ha scritto: -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] Which pci-e card?
I run opensuse. I'm not going to pretend to be an expert at pci slots, but the cards never swapped around for me. What you probably should do is find a forum related to Digidesign (protools?). The boxes were used in multitrack audio recording prior to the availability of multitrack sound cards. I would think if the pci slots were not static, the recording studios would have complained about it. -Original Message- From: owl...@gmail.com owl...@gmail.com Date: Mon, 20 Jun 2011 22:14:04 To: li...@lazygranch.com Cc: alsa-useralsa-user@lists.sourceforge.net Subject: Re: [Alsa-user] Which pci-e card? Another question i have decided to buy magma box 7 pci. Are you sure debian 6 always load the magma pci slots in the same order? Otherwise you can understand that for me is an insurmountable problem Thanks Il giorno 16/giu/2011 18.42, li...@lazygranch.com ha scritto: -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] First post
I think your statement here i.e. how exactly would you create your tarball? From a diff of an entire backup before and after make install? best sums it up. Without a staging directory to install to, you would have to parse the entire FS in order to find what the make install step did. By using a staging directory, you still run make install, it just installs everything in it's retained hierarchy within that staging directory. That's why I said /opt/staging/alsa/bin in Kubuntu (build OS) becomes /bin in the custom distro. That's what the DESTDIR parameter does, it allows you to retain whatever directory hierarchy to use, but during the make install phase, instead of using / as the root, it uses whatever you include (e.g. DESTDIR=/opt/staging/alsa) as the value pre-pended for root. Honestly, at this point, we've gotten way off topic. lol These are all issues for me to work out, but appreciate you guys efforts. :) Presently, I'm thinking that alsa-utils (as we've determined alsa-driver probably doesn't have to be installed) is failing to compile because it's looking under /... for the header files and not /opt/staging/alsa/... Is there a way to make the configure script look into that directory for the header files during the configure phase? Thanks again for everyone's continued efforts in getting this matter resolved. Dave On 06/20/2011 04:06 PM, James Shatto wrote: Ummm. I'm not sure if I follow you. $ make will build the objects and stuff in the current path of your source tree. $ make install copies the executables to the system usable locations. /usr/bin/ /lib/modules/. /usr/share/doc/. (which is why you need to be root in a lot of cases to run make install, but not to run make) A package maintainer will likely use stuff like what's in debian/rules debian/binary and such to build a package manager package, instead of using make install to place the important components (results) where they need to be. A package manager package lets you keep track of what got installed and where and the package provides additional features useful for long term maintenance and/or large scale deployment. If you want to build a package (i.e. .deb) you'd use those tools for that to do that. Otherwise you have to at least mimic make install. Which is a bit futile IMO, given that you could just run make install. i.e. how exactly would you create your tarball? From a diff of an entire backup before and after make install? By doing everything done by make install manually? That's fine for relatively small things like alsa. But for X, KDE, ???, and other more bulky entities. You'd need a couple lifetimes of spare time to re-invent make install. And scons install and and ... and ... Also bear in mind that if you're building something on a system other than the one where it will be deployed. You will run into some version compatibility issues. Just a minor difference in the API between version 1.0.24 and 1.0.25 could make things unusable. And as previously mentioned, alsa comes with the 2.6 kernel, so you'll have an existing version already in place that you will need to deal with, one way or another. When there's multiple versions of things, at runtime things like to load in alphabetical order or ascii order at least. Which generally means the that OLDer version takes priority. So even if you install your newer version, it's probably going to be ignored unless you remove or replace the older version. The manual approach to dependency hell I guess, of sorts. Lots of little things that will keep you from succeeding. It's probably time better spent learning an existing package management system IMO. Than to create your own. Especially if you're on your own and not part of team. But it's almost all open source so if you can read the source, everything that you need to know is there in one form or another. - James On 6/20/11, David Hendersondhender...@digital-pipe.com wrote: On 06/20/2011 11:52 AM, Pierre Lorenzon wrote: Hi, From: David Hendersondhender...@digital-pipe.com Subject: Re: [Alsa-user] First post Date: Sun, 19 Jun 2011 15:28:48 -0400 Thanks for the reply Pierre. I checked into the blfs book, but it merely says these five chapters will cover alsa and then gives you a basic type configure make. This is obviously not going to answer the questions below. :) Any other thoughts? Dave On 06/19/2011 11:22 PM, Pierre Lorenzon wrote: Hi, It looks like to me such questions are well answered in the blfs book. I personnaly think that the latter is a very good tool to build his own custom distro. Bests Pierre From: David Hendersondhender...@digital-pipe.com Subject: [Alsa-user] First post Date: Sun, 19 Jun 2011 14:41:08 -0400 Hi everyone! I'm currently expanding my knowledge of GNU/Linux to include building packages from scratch towards an overall goal of a custom distro.
Re: [Alsa-user] First post
This is part of the reason that I use --prefix=/usr because the /usr/includes/ are also affected by the --prefix option (i.e. /usr/local/includes / which is empty). And I've never really gotten into the changing $PATH part of things. But there's a whole slew of -I and -L options (with a different case / case sensitive) for gcc to bypass / customize a lot of that. A real PITB IMO. But just my opinion. i.e. Use what is already there, not re-invent it in your image. And yes a bit OT at this point. - James On 6/20/11, David Henderson dhender...@digital-pipe.com wrote: I think your statement here i.e. how exactly would you create your tarball? From a diff of an entire backup before and after make install? best sums it up. Without a staging directory to install to, you would have to parse the entire FS in order to find what the make install step did. By using a staging directory, you still run make install, it just installs everything in it's retained hierarchy within that staging directory. That's why I said /opt/staging/alsa/bin in Kubuntu (build OS) becomes /bin in the custom distro. That's what the DESTDIR parameter does, it allows you to retain whatever directory hierarchy to use, but during the make install phase, instead of using / as the root, it uses whatever you include (e.g. DESTDIR=/opt/staging/alsa) as the value pre-pended for root. Honestly, at this point, we've gotten way off topic. lol These are all issues for me to work out, but appreciate you guys efforts. :) Presently, I'm thinking that alsa-utils (as we've determined alsa-driver probably doesn't have to be installed) is failing to compile because it's looking under /... for the header files and not /opt/staging/alsa/... Is there a way to make the configure script look into that directory for the header files during the configure phase? Thanks again for everyone's continued efforts in getting this matter resolved. Dave On 06/20/2011 04:06 PM, James Shatto wrote: Ummm. I'm not sure if I follow you. $ make will build the objects and stuff in the current path of your source tree. $ make install copies the executables to the system usable locations. /usr/bin/ /lib/modules/. /usr/share/doc/. (which is why you need to be root in a lot of cases to run make install, but not to run make) A package maintainer will likely use stuff like what's in debian/rules debian/binary and such to build a package manager package, instead of using make install to place the important components (results) where they need to be. A package manager package lets you keep track of what got installed and where and the package provides additional features useful for long term maintenance and/or large scale deployment. If you want to build a package (i.e. .deb) you'd use those tools for that to do that. Otherwise you have to at least mimic make install. Which is a bit futile IMO, given that you could just run make install. i.e. how exactly would you create your tarball? From a diff of an entire backup before and after make install? By doing everything done by make install manually? That's fine for relatively small things like alsa. But for X, KDE, ???, and other more bulky entities. You'd need a couple lifetimes of spare time to re-invent make install. And scons install and and ... and ... Also bear in mind that if you're building something on a system other than the one where it will be deployed. You will run into some version compatibility issues. Just a minor difference in the API between version 1.0.24 and 1.0.25 could make things unusable. And as previously mentioned, alsa comes with the 2.6 kernel, so you'll have an existing version already in place that you will need to deal with, one way or another. When there's multiple versions of things, at runtime things like to load in alphabetical order or ascii order at least. Which generally means the that OLDer version takes priority. So even if you install your newer version, it's probably going to be ignored unless you remove or replace the older version. The manual approach to dependency hell I guess, of sorts. Lots of little things that will keep you from succeeding. It's probably time better spent learning an existing package management system IMO. Than to create your own. Especially if you're on your own and not part of team. But it's almost all open source so if you can read the source, everything that you need to know is there in one form or another. - James On 6/20/11, David Hendersondhender...@digital-pipe.com wrote: On 06/20/2011 11:52 AM, Pierre Lorenzon wrote: Hi, From: David Hendersondhender...@digital-pipe.com Subject: Re: [Alsa-user] First post Date: Sun, 19 Jun 2011 15:28:48 -0400 Thanks for the reply Pierre. I checked into the blfs book, but it merely says these five chapters will cover alsa and then gives you a basic type configure make. This is obviously
[Alsa-user] ALSA lib audio/pcm_bluetooth.c:1607:(audioservice_expect)
Hello, I use a bluetooth headset. With some SDL applications[1][2][3][4] I got this error : ALSA lib audio/pcm_bluetooth.c:1607:(audioservice_expect) BT_OPEN failed : Invalid argument(22) and audio doesn't work. Whereas with other applications[5][6] I got no error message and the audio works. I think all SDL applications have this problem. Can you tell me how to resolve this problem? [1]supertux [2]frozen-bubble [3]pingus [4]milkytracker [5]vlc [6]audacity -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
