Re: [Alsa-user] how to make all 8 channels play in a USB sound card ?
Sergei Steshenko wrote: > the card is shown as 7.1. so an 8 channel playback should be possible Does speaker-test work? > I've enabled playback through "Line", I hear nothing when headphones are > plugged into line. I'd guess the "Line" controls are for playback from the line input. Regards, Clemens -- LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
[Alsa-user] how to make all 8 channels play in a USB sound card ?
Hello, I have a sound card listed as Bus 002 Device 002: ID 0d8c:0102 C-Media Electronics, Inc. CM106 Like Sound Device . The card physically is this: http://www.buyincoins.com/new_en/details/usb-2-0-6-channel-7-1-external-audio-sound-card-s-pdif-product-724.html . The card mostly works - I can easily output to "FRONT OUT", "REAR OUT", "CEN/BASS OUT". And I can capture through "LINE IN". I am not interested in the rest of interfaces. One can see in the URL above that the mentioned interfaces are the only default playback interfaces, however, the card is shown as 7.1. so an 8 channel playback should be possible (I need the card for measurement purposes - not for 7.1 amplifier/speakers). Here is what 'amixer -c 2 contents' shows: " numid=14,iface=MIXER,name='PCM Capture Source' ; type=ENUMERATED,access=rw--,values=1,items=4 ; Item #0 'Mic' ; Item #1 'Line' ; Item #2 'IEC958 In' ; Item #3 'Mixer' : values=2 numid=12,iface=MIXER,name='PCM Capture Switch' ; type=BOOLEAN,access=rw--,values=1 : values=off numid=13,iface=MIXER,name='PCM Capture Volume' ; type=INTEGER,access=rw---R--,values=2,min=0,max=6928,step=0 : values=6928,6928 | dBscale-min=-16.00dB,step=0.00dB,mute=0 numid=3,iface=MIXER,name='Line Playback Switch' ; type=BOOLEAN,access=rw--,values=1 : values=on numid=4,iface=MIXER,name='Line Playback Volume' ; type=INTEGER,access=rw---R--,values=2,min=0,max=8065,step=0 : values=8065,8065 | dBscale-min=-24.00dB,step=0.00dB,mute=0 numid=9,iface=MIXER,name='Line Capture Switch' ; type=BOOLEAN,access=rw--,values=1 : values=off numid=10,iface=MIXER,name='Line Capture Volume' ; type=INTEGER,access=rw---R--,values=2,min=0,max=6928,step=0 : values=0,0 | dBscale-min=-16.00dB,step=0.00dB,mute=0 numid=1,iface=MIXER,name='Mic Playback Switch' ; type=BOOLEAN,access=rw--,values=1 : values=off numid=2,iface=MIXER,name='Mic Playback Volume' ; type=INTEGER,access=rw---R--,values=2,min=0,max=8065,step=0 : values=8065,8065 | dBscale-min=-24.00dB,step=0.00dB,mute=0 numid=7,iface=MIXER,name='Mic Capture Switch' ; type=BOOLEAN,access=rw--,values=1 : values=on numid=8,iface=MIXER,name='Mic Capture Volume' ; type=INTEGER,access=rw---R--,values=2,min=0,max=6928,step=0 : values=6928,6928 | dBscale-min=-16.00dB,step=0.00dB,mute=0 numid=11,iface=MIXER,name='IEC958 In Capture Switch' ; type=BOOLEAN,access=rw--,values=1 : values=off numid=5,iface=MIXER,name='Speaker Playback Switch' ; type=BOOLEAN,access=rw--,values=1 : values=on numid=6,iface=MIXER,name='Speaker Playback Volume' ; type=INTEGER,access=rw---R--,values=8,min=0,max=197,step=0 : values=197,197,197,197,197,197,197,197 | dBscale-min=-36.93dB,step=0.18dB,mute=0 sergei@amdam2:~> amixer -c 2 cset numid=4, sergei@amdam2:~> amixer -c 2 cset numid=4 8065 numid=4,iface=MIXER,name='Line Playback Volume' ; type=INTEGER,access=rw---R--,values=2,min=0,max=8065,step=0 : values=8065,8065 | dBscale-min=-24.00dB,step=0.00dB,mute=0 ". Even though I have: 1) numid=4,iface=MIXER,name='Line Playback Volume' ; type=INTEGER,access=rw---R--,values=2,min=0,max=8065,step=0 : values=8065,8065 2) numid=3,iface=MIXER,name='Line Playback Switch' ; type=BOOLEAN,access=rw--,values=1 : values=on , i.e. I think (wrongly ?) I've enabled playback through "Line", I hear nothing when headphones are plugged into line. Any ideas ? Thanks, Sergei. -- LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] Ticks when playing to USB DAC at high sample rates
On 05.11.2012 23:29, Jeffrey Barish wrote: > On Mon 05 November 2012 16:03:00 Daniel Mack wrote: >> Hi Jeff, >> >> On 05.11.2012 02:53, Jeffrey Barish wrote: >>> On Sun 04 November 2012 11:39:48 Daniel Mack wrote: [cc alsa-devel] On 04.11.2012 02:25, Jeffrey Barish wrote: > On Fri 26 October 2012 15:21:06 Jeffrey Barish wrote: >> On Fri 26 October 2012 21:47:05 Daniel Mack wrote: >>> On 26.10.2012 21:43, Jeffrey Barish wrote: On Thu 25 October 2012 19:10:45 Daniel Mack wrote: > On 25.10.2012 17:18, Jeffrey Barish wrote: >> I found something in the snd_usb_audio code (in endpoint.c) that >> could >> explain one of the problems I have observed (the ticks). I would >> normally test my theory by modifying the code. In this case, I >> would >> like to stick in a print statement to see what values are being >> assigned >> to certain variables. Unfortunately, I am too ignorant to do >> something >> even this trivial as I have never worked on kernel code. I think I >> am >> supposed to use printk, > > printk is nice for simple debugging, yes. But note that this call is > timing critical and should not be used in "fast path" code. > Introducing > a printk for each received packet for example will almost certainly > make > the driver behave quite differently. > >> but beyond that I am lost. Can someone provide >> me with some directions? I need to know how to make the driver. To >> that >> end, I probably will have to install additional packages. After >> making >> the driver, I need to know how to install it over the existing >> driver. > > Here's one way to do it: > > 1. git clone > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git (your > patch should apply on top of this tree eventually) > 2. cd sound > 3. zcat /proc/config.gz >.config > 4. build and install the kernel image. How that is done depends on > the > distribution you're using. For Ubuntu follow the docs at [1] (start > at > point #5). For Fedora and others, something like "make && make > install" > should do > 5. reboot and check that the new kernel is running > 6. hack on sound/usb > 7. make M=sound/usb > 8. reload the module with "sudo rmmod snd_usb_audio; sudo insmod > sound/usb/snd-usb-audio.ko" (better plug out the device before so > you > always have the same defined point of start) > > > Hope that works for you. > > > Daniel > > [1] https://wiki.ubuntu.com/KernelTeam/GitKernelBuild Your directions were almost perfect, so even I was able to build the kernel. I made a discovery using the new kernel that might help someone more familiar with the code than I am to localize the problem. I am still hearing the blip when I play audio sampled at 88.2 kHz, but I just noticed that the blip is perfectly periodic, with a period of about 16.4 seconds. I am playing a sine wave synthesized using GStreamer using the following command: gst-launch audiotestsrc volume=0.01 ! audio/x-raw-float, width=64, rate=88200, channels=2, endianness=1234 ! audioconvert ! alsasink A sine wave makes it easier to hear the blip. Does this clue suggest anything? I also want to mention that when I use the new kernel, I do not get the ticks at either 88.2 or 96 kHz even when I do not use the external USB hub. I plan next to back up to the 3.6.2 kernel to see whether I still get ticks there. >>> >>> Which kernel did you use when you heard the 'blibs'? >> >> The latest news is bad. I am on 3.2.0 now. The USB DAC is working >> perfectly at this moment at both 96 kHz and 88.2 kHz without the >> external >> USB hub (imagine calling that bad news). If I set the srate to 88.2 >> kHz >> and stop and start the sine wave, sometimes I get the blip. Forget >> about >> its being periodic. It was definitely periodic before lunch; now I >> usually >> get random intervals if I get any blips at all. As I am typing this >> message, I can't get blips at all. There was some correlation between >> changing sample rates and blips, but I can't reproduce that behavior >> now. >> What is most weird is that I haven't gotten any ticks since lunch with >> any >> kernel or with either sample rate, yet they were reliable earlier today >> unless I used the external USB hub. I obviously need
Re: [Alsa-user] Ticks when playing to USB DAC at high sample rates
On Mon 05 November 2012 16:03:00 Daniel Mack wrote: > Hi Jeff, > > On 05.11.2012 02:53, Jeffrey Barish wrote: > > On Sun 04 November 2012 11:39:48 Daniel Mack wrote: > >> [cc alsa-devel] > >> > >> On 04.11.2012 02:25, Jeffrey Barish wrote: > >>> On Fri 26 October 2012 15:21:06 Jeffrey Barish wrote: > On Fri 26 October 2012 21:47:05 Daniel Mack wrote: > > On 26.10.2012 21:43, Jeffrey Barish wrote: > >> On Thu 25 October 2012 19:10:45 Daniel Mack wrote: > >>> On 25.10.2012 17:18, Jeffrey Barish wrote: > I found something in the snd_usb_audio code (in endpoint.c) that > could > explain one of the problems I have observed (the ticks). I would > normally test my theory by modifying the code. In this case, I > would > like to stick in a print statement to see what values are being > assigned > to certain variables. Unfortunately, I am too ignorant to do > something > even this trivial as I have never worked on kernel code. I think I > am > supposed to use printk, > >>> > >>> printk is nice for simple debugging, yes. But note that this call is > >>> timing critical and should not be used in "fast path" code. > >>> Introducing > >>> a printk for each received packet for example will almost certainly > >>> make > >>> the driver behave quite differently. > >>> > but beyond that I am lost. Can someone provide > me with some directions? I need to know how to make the driver. To > that > end, I probably will have to install additional packages. After > making > the driver, I need to know how to install it over the existing > driver. > >>> > >>> Here's one way to do it: > >>> > >>> 1. git clone > >>> git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git (your > >>> patch should apply on top of this tree eventually) > >>> 2. cd sound > >>> 3. zcat /proc/config.gz >.config > >>> 4. build and install the kernel image. How that is done depends on > >>> the > >>> distribution you're using. For Ubuntu follow the docs at [1] (start > >>> at > >>> point #5). For Fedora and others, something like "make && make > >>> install" > >>> should do > >>> 5. reboot and check that the new kernel is running > >>> 6. hack on sound/usb > >>> 7. make M=sound/usb > >>> 8. reload the module with "sudo rmmod snd_usb_audio; sudo insmod > >>> sound/usb/snd-usb-audio.ko" (better plug out the device before so > >>> you > >>> always have the same defined point of start) > >>> > >>> > >>> Hope that works for you. > >>> > >>> > >>> Daniel > >>> > >>> [1] https://wiki.ubuntu.com/KernelTeam/GitKernelBuild > >> > >> Your directions were almost perfect, so even I was able to build the > >> kernel. I made a discovery using the new kernel that might help > >> someone > >> more familiar with the code than I am to localize the problem. I am > >> still hearing the blip when I play audio sampled at 88.2 kHz, but I > >> just > >> noticed that the blip is perfectly periodic, with a period of about > >> 16.4 > >> seconds. I am playing a sine wave synthesized using GStreamer using > >> the > >> following command: > >> > >> gst-launch audiotestsrc volume=0.01 ! audio/x-raw-float, width=64, > >> rate=88200, channels=2, endianness=1234 ! audioconvert ! alsasink > >> > >> A sine wave makes it easier to hear the blip. Does this clue suggest > >> anything? > >> > >> I also want to mention that when I use the new kernel, I do not get > >> the > >> ticks at either 88.2 or 96 kHz even when I do not use the external > >> USB > >> hub. I plan next to back up to the 3.6.2 kernel to see whether I > >> still > >> get ticks there. > > > > Which kernel did you use when you heard the 'blibs'? > > The latest news is bad. I am on 3.2.0 now. The USB DAC is working > perfectly at this moment at both 96 kHz and 88.2 kHz without the > external > USB hub (imagine calling that bad news). If I set the srate to 88.2 > kHz > and stop and start the sine wave, sometimes I get the blip. Forget > about > its being periodic. It was definitely periodic before lunch; now I > usually > get random intervals if I get any blips at all. As I am typing this > message, I can't get blips at all. There was some correlation between > changing sample rates and blips, but I can't reproduce that behavior > now. > What is most weird is that I haven't gotten any ticks since lunch with > any > kernel or with either sample rate, yet they were reliable earlier today > unless I used the external USB hub. I obviously need to experiment some > more
Re: [Alsa-user] Ticks when playing to USB DAC at high sample rates
Hi Jeff, On 05.11.2012 02:53, Jeffrey Barish wrote: > On Sun 04 November 2012 11:39:48 Daniel Mack wrote: >> [cc alsa-devel] >> >> On 04.11.2012 02:25, Jeffrey Barish wrote: >>> On Fri 26 October 2012 15:21:06 Jeffrey Barish wrote: On Fri 26 October 2012 21:47:05 Daniel Mack wrote: > On 26.10.2012 21:43, Jeffrey Barish wrote: >> On Thu 25 October 2012 19:10:45 Daniel Mack wrote: >>> On 25.10.2012 17:18, Jeffrey Barish wrote: I found something in the snd_usb_audio code (in endpoint.c) that could explain one of the problems I have observed (the ticks). I would normally test my theory by modifying the code. In this case, I would like to stick in a print statement to see what values are being assigned to certain variables. Unfortunately, I am too ignorant to do something even this trivial as I have never worked on kernel code. I think I am supposed to use printk, >>> >>> printk is nice for simple debugging, yes. But note that this call is >>> timing critical and should not be used in "fast path" code. >>> Introducing >>> a printk for each received packet for example will almost certainly >>> make >>> the driver behave quite differently. >>> but beyond that I am lost. Can someone provide me with some directions? I need to know how to make the driver. To that end, I probably will have to install additional packages. After making the driver, I need to know how to install it over the existing driver. >>> >>> Here's one way to do it: >>> >>> 1. git clone >>> git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git (your >>> patch should apply on top of this tree eventually) >>> 2. cd sound >>> 3. zcat /proc/config.gz >.config >>> 4. build and install the kernel image. How that is done depends on the >>> distribution you're using. For Ubuntu follow the docs at [1] (start at >>> point #5). For Fedora and others, something like "make && make >>> install" >>> should do >>> 5. reboot and check that the new kernel is running >>> 6. hack on sound/usb >>> 7. make M=sound/usb >>> 8. reload the module with "sudo rmmod snd_usb_audio; sudo insmod >>> sound/usb/snd-usb-audio.ko" (better plug out the device before so you >>> always have the same defined point of start) >>> >>> >>> Hope that works for you. >>> >>> >>> Daniel >>> >>> [1] https://wiki.ubuntu.com/KernelTeam/GitKernelBuild >> >> Your directions were almost perfect, so even I was able to build the >> kernel. I made a discovery using the new kernel that might help someone >> more familiar with the code than I am to localize the problem. I am >> still hearing the blip when I play audio sampled at 88.2 kHz, but I >> just >> noticed that the blip is perfectly periodic, with a period of about >> 16.4 >> seconds. I am playing a sine wave synthesized using GStreamer using >> the >> following command: >> >> gst-launch audiotestsrc volume=0.01 ! audio/x-raw-float, width=64, >> rate=88200, channels=2, endianness=1234 ! audioconvert ! alsasink >> >> A sine wave makes it easier to hear the blip. Does this clue suggest >> anything? >> >> I also want to mention that when I use the new kernel, I do not get the >> ticks at either 88.2 or 96 kHz even when I do not use the external USB >> hub. I plan next to back up to the 3.6.2 kernel to see whether I still >> get ticks there. > > Which kernel did you use when you heard the 'blibs'? The latest news is bad. I am on 3.2.0 now. The USB DAC is working perfectly at this moment at both 96 kHz and 88.2 kHz without the external USB hub (imagine calling that bad news). If I set the srate to 88.2 kHz and stop and start the sine wave, sometimes I get the blip. Forget about its being periodic. It was definitely periodic before lunch; now I usually get random intervals if I get any blips at all. As I am typing this message, I can't get blips at all. There was some correlation between changing sample rates and blips, but I can't reproduce that behavior now. What is most weird is that I haven't gotten any ticks since lunch with any kernel or with either sample rate, yet they were reliable earlier today unless I used the external USB hub. I obviously need to experiment some more to see whether I can observe a pattern. >>> >>> To conclude (?) this thread, I am now convinced that the anomalies I >>> observed were unrelated to the device driver. I had two theories >>> remaining. One was that the problem was somehow related to an >>> overheating problem. I used a heat gun to convince myself that the >>> theory was wrong. The other was that the problem had someth
Re: [Alsa-user] Ticks when playing to USB DAC at high sample rates
On Sun 04 November 2012 11:39:48 Daniel Mack wrote: > [cc alsa-devel] > > On 04.11.2012 02:25, Jeffrey Barish wrote: > > On Fri 26 October 2012 15:21:06 Jeffrey Barish wrote: > >> On Fri 26 October 2012 21:47:05 Daniel Mack wrote: > >>> On 26.10.2012 21:43, Jeffrey Barish wrote: > On Thu 25 October 2012 19:10:45 Daniel Mack wrote: > > On 25.10.2012 17:18, Jeffrey Barish wrote: > >> I found something in the snd_usb_audio code (in endpoint.c) that > >> could > >> explain one of the problems I have observed (the ticks). I would > >> normally test my theory by modifying the code. In this case, I would > >> like to stick in a print statement to see what values are being > >> assigned > >> to certain variables. Unfortunately, I am too ignorant to do > >> something > >> even this trivial as I have never worked on kernel code. I think I am > >> supposed to use printk, > > > > printk is nice for simple debugging, yes. But note that this call is > > timing critical and should not be used in "fast path" code. > > Introducing > > a printk for each received packet for example will almost certainly > > make > > the driver behave quite differently. > > > >> but beyond that I am lost. Can someone provide > >> me with some directions? I need to know how to make the driver. To > >> that > >> end, I probably will have to install additional packages. After > >> making > >> the driver, I need to know how to install it over the existing > >> driver. > > > > Here's one way to do it: > > > > 1. git clone > > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git (your > > patch should apply on top of this tree eventually) > > 2. cd sound > > 3. zcat /proc/config.gz >.config > > 4. build and install the kernel image. How that is done depends on the > > distribution you're using. For Ubuntu follow the docs at [1] (start at > > point #5). For Fedora and others, something like "make && make > > install" > > should do > > 5. reboot and check that the new kernel is running > > 6. hack on sound/usb > > 7. make M=sound/usb > > 8. reload the module with "sudo rmmod snd_usb_audio; sudo insmod > > sound/usb/snd-usb-audio.ko" (better plug out the device before so you > > always have the same defined point of start) > > > > > > Hope that works for you. > > > > > > Daniel > > > > [1] https://wiki.ubuntu.com/KernelTeam/GitKernelBuild > > Your directions were almost perfect, so even I was able to build the > kernel. I made a discovery using the new kernel that might help someone > more familiar with the code than I am to localize the problem. I am > still hearing the blip when I play audio sampled at 88.2 kHz, but I > just > noticed that the blip is perfectly periodic, with a period of about > 16.4 > seconds. I am playing a sine wave synthesized using GStreamer using > the > following command: > > gst-launch audiotestsrc volume=0.01 ! audio/x-raw-float, width=64, > rate=88200, channels=2, endianness=1234 ! audioconvert ! alsasink > > A sine wave makes it easier to hear the blip. Does this clue suggest > anything? > > I also want to mention that when I use the new kernel, I do not get the > ticks at either 88.2 or 96 kHz even when I do not use the external USB > hub. I plan next to back up to the 3.6.2 kernel to see whether I still > get ticks there. > >>> > >>> Which kernel did you use when you heard the 'blibs'? > >> > >> The latest news is bad. I am on 3.2.0 now. The USB DAC is working > >> perfectly at this moment at both 96 kHz and 88.2 kHz without the external > >> USB hub (imagine calling that bad news). If I set the srate to 88.2 kHz > >> and stop and start the sine wave, sometimes I get the blip. Forget about > >> its being periodic. It was definitely periodic before lunch; now I > >> usually > >> get random intervals if I get any blips at all. As I am typing this > >> message, I can't get blips at all. There was some correlation between > >> changing sample rates and blips, but I can't reproduce that behavior now. > >> What is most weird is that I haven't gotten any ticks since lunch with > >> any > >> kernel or with either sample rate, yet they were reliable earlier today > >> unless I used the external USB hub. I obviously need to experiment some > >> more to see whether I can observe a pattern. > > > > To conclude (?) this thread, I am now convinced that the anomalies I > > observed were unrelated to the device driver. I had two theories > > remaining. One was that the problem was somehow related to an > > overheating problem. I used a heat gun to convince myself that the > > theory was wrong. The other was that the problem had something to do > > with services running in th
