Re: [Alsa-user] Ticks when playing to USB DAC at high sample rates
Hi Jeffrey, sorry for the late reply. On 08.11.2012 19:54, Jeffrey Barish wrote: On Wed 07 November 2012 10:01:14 Daniel Mack wrote: On 07.11.2012 00:54, Jeffrey Barish wrote: I guess that snd_usb_pcm_prepare is called by the core usb system to prepare the snd driver. Anyway, snd_usb_pcm_prepare calls configure_endpoint with a substream. Then configure_endpoint calls snd_usb_endpoint_set_params with the data endpoint that corresponds to the substream. snd_usb_endpoint_set_params calls data_ep_set_params with the data ep and data_ep_set_params sets nurbs to 2 for the data endpoint. snd_usb_endpoint_set_params has code to call sync_ep_set_params when the endpoint is type sync. sync_ep_set_params sets nurbs to 4 (why?). However, snd_usb_endpoint_set_params never invokes the call to sync_ep_set_params because ep-type is always data. Back up: snd_usb_endpoint_set_params is called from configure_endpoint. It is called from an if block contingent on the substream's having a sync endpoint. It does. However, the call to snd_usb_endpoint_set_params passes subs-data_endpoint as the first argument, so snd_usb_endpoint_set_params simply repeats the operations it performed as a result of the previous invocation. I presume that the first argument to the second call to snd_usb_endpoint_set_params should be subs-sync_endpoint. Eh. You clearly spotted a bug here. The rally interesting thing is that that it didn't bite us earlier, as it's in since 3.6. Here's the diff. I can't figure out how to submit a patch. --- sound/usb/pcm.c.orig2012-11-08 11:43:57.309732860 -0700 +++ sound/usb/pcm.c 2012-11-08 11:41:06.512420658 -0700 @@ -456,7 +456,7 @@ static int configure_endpoint(struct snd return ret; if (subs-sync_endpoint) - ret = snd_usb_endpoint_set_params(subs-data_endpoint, + ret = snd_usb_endpoint_set_params(subs-sync_endpoint, subs-pcm_format, subs-channels, subs-period_bytes, Thanks - I just sent out a patch for this. Daniel -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ 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 07.11.2012 18:05, Jeffrey Barish wrote: On Wed 07 November 2012 10:04:14 Daniel Mack wrote: On 07.11.2012 10:01, Daniel Mack wrote: On 07.11.2012 00:54, Jeffrey Barish wrote: I guess that snd_usb_pcm_prepare is called by the core usb system to prepare the snd driver. Anyway, snd_usb_pcm_prepare calls configure_endpoint with a substream. Then configure_endpoint calls snd_usb_endpoint_set_params with the data endpoint that corresponds to the substream. snd_usb_endpoint_set_params calls data_ep_set_params with the data ep and data_ep_set_params sets nurbs to 2 for the data endpoint. snd_usb_endpoint_set_params has code to call sync_ep_set_params when the endpoint is type sync. sync_ep_set_params sets nurbs to 4 (why?). However, snd_usb_endpoint_set_params never invokes the call to sync_ep_set_params because ep-type is always data. Back up: snd_usb_endpoint_set_params is called from configure_endpoint. It is called from an if block contingent on the substream's having a sync endpoint. It does. However, the call to snd_usb_endpoint_set_params passes subs-data_endpoint as the first argument, so snd_usb_endpoint_set_params simply repeats the operations it performed as a result of the previous invocation. I presume that the first argument to the second call to snd_usb_endpoint_set_params should be subs-sync_endpoint. Eh. You clearly spotted a bug here. The rally interesting thing is that that it didn't bite us earlier, as it's in since 3.6. I made that change. Now freqm does change. However, I am getting tons of ticks. Now it sounds as if the payload size is always wrong. Oh, 44.1 kHz works. 48 kHz works. 88.2 and 96 don't work. That's a different issue. Would you like to prepare a patch for the issue above please? I don't know how to prepare a patch, so I'm inclined to fix the remaining problem before stopping to figure out the patch problem. I didn't get your previous email. I hope that it contained some suggestions on what to look for to solve the remaining problem. Please send it again. The problem seems to be related to timing considering that the driver works perfectly 5-10% of the time, but timing of what? I don't know what to look for. So with the first problem sorted out, I guess the other one is related to to inexactly reported data feedback from the device. Some explanation about the current code. The code in the lower half in snd_usb_handle_sync_urb(), endpoint.c does some auto-detection of the feedback rate format. This is done in order to cope with all the many devices use have all sorts of rate formats. When called for the first time after a stream start, it shifts the received value until it matches the nominal sampling frequency with an accuracy of +50% or -25%. Once the shift value is determined, it is saved for later reference. In case the values get badly of of bounds over subsequent calls, the code falls back to the auto-detection mode again. In other words: if the device reports a bogus value in the very first feedback packet, but stays inside the limits of the thresholds that would make it fall back to auto-detection, the shift value will always be wrong for the duration of that stream, resulting in bogus data rates produced by the driver. This is where I would have a look. Add some printk()s in the if (unlikely(ep-freqshift == INT_MIN)) case and dump the values that are detected, for both a working and non-working case. Let me know if that brings you anywhere :) Daniel -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ 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 22.11.2012 20:40, Daniel Mack wrote: On 07.11.2012 18:05, Jeffrey Barish wrote: On Wed 07 November 2012 10:04:14 Daniel Mack wrote: On 07.11.2012 10:01, Daniel Mack wrote: On 07.11.2012 00:54, Jeffrey Barish wrote: I guess that snd_usb_pcm_prepare is called by the core usb system to prepare the snd driver. Anyway, snd_usb_pcm_prepare calls configure_endpoint with a substream. Then configure_endpoint calls snd_usb_endpoint_set_params with the data endpoint that corresponds to the substream. snd_usb_endpoint_set_params calls data_ep_set_params with the data ep and data_ep_set_params sets nurbs to 2 for the data endpoint. snd_usb_endpoint_set_params has code to call sync_ep_set_params when the endpoint is type sync. sync_ep_set_params sets nurbs to 4 (why?). However, snd_usb_endpoint_set_params never invokes the call to sync_ep_set_params because ep-type is always data. Back up: snd_usb_endpoint_set_params is called from configure_endpoint. It is called from an if block contingent on the substream's having a sync endpoint. It does. However, the call to snd_usb_endpoint_set_params passes subs-data_endpoint as the first argument, so snd_usb_endpoint_set_params simply repeats the operations it performed as a result of the previous invocation. I presume that the first argument to the second call to snd_usb_endpoint_set_params should be subs-sync_endpoint. Eh. You clearly spotted a bug here. The rally interesting thing is that that it didn't bite us earlier, as it's in since 3.6. I made that change. Now freqm does change. However, I am getting tons of ticks. Now it sounds as if the payload size is always wrong. Oh, 44.1 kHz works. 48 kHz works. 88.2 and 96 don't work. That's a different issue. Would you like to prepare a patch for the issue above please? I don't know how to prepare a patch, so I'm inclined to fix the remaining problem before stopping to figure out the patch problem. I didn't get your previous email. I hope that it contained some suggestions on what to look for to solve the remaining problem. Please send it again. The problem seems to be related to timing considering that the driver works perfectly 5-10% of the time, but timing of what? I don't know what to look for. So with the first problem sorted out, I guess the other one is related to to inexactly reported data feedback from the device. Some explanation about the current code. The code in the lower half in snd_usb_handle_sync_urb(), endpoint.c does some auto-detection of the feedback rate format. This is done in order to cope with all the many devices use have all sorts of rate formats. When called for the first time after a stream start, it shifts the received value until it matches the nominal sampling frequency with an accuracy of +50% or -25%. Once the shift value is determined, it is saved for later reference. In case the values get badly of of bounds over subsequent calls, the code falls back to the auto-detection mode again. In other words: if the device reports a bogus value in the very first feedback packet, but stays inside the limits of the thresholds that would make it fall back to auto-detection, the shift value will always be wrong for the duration of that stream, resulting in bogus data rates produced by the driver. This is where I would have a look. Add some printk()s in the if (unlikely(ep-freqshift == INT_MIN)) case and dump the values that are detected, for both a working and non-working case. Btw - if that is the case, and the device stabilizes after a while, one way to fix that problem is to simply ignore the first x packets that are received. And there's already a quirks framework for that: initalize ep-skip_packets from snd_usb_endpoint_start_quirk(). Daniel -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ 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 Wed 07 November 2012 10:01:14 Daniel Mack wrote: On 07.11.2012 00:54, Jeffrey Barish wrote: I guess that snd_usb_pcm_prepare is called by the core usb system to prepare the snd driver. Anyway, snd_usb_pcm_prepare calls configure_endpoint with a substream. Then configure_endpoint calls snd_usb_endpoint_set_params with the data endpoint that corresponds to the substream. snd_usb_endpoint_set_params calls data_ep_set_params with the data ep and data_ep_set_params sets nurbs to 2 for the data endpoint. snd_usb_endpoint_set_params has code to call sync_ep_set_params when the endpoint is type sync. sync_ep_set_params sets nurbs to 4 (why?). However, snd_usb_endpoint_set_params never invokes the call to sync_ep_set_params because ep-type is always data. Back up: snd_usb_endpoint_set_params is called from configure_endpoint. It is called from an if block contingent on the substream's having a sync endpoint. It does. However, the call to snd_usb_endpoint_set_params passes subs-data_endpoint as the first argument, so snd_usb_endpoint_set_params simply repeats the operations it performed as a result of the previous invocation. I presume that the first argument to the second call to snd_usb_endpoint_set_params should be subs-sync_endpoint. Eh. You clearly spotted a bug here. The rally interesting thing is that that it didn't bite us earlier, as it's in since 3.6. Here's the diff. I can't figure out how to submit a patch. --- sound/usb/pcm.c.orig2012-11-08 11:43:57.309732860 -0700 +++ sound/usb/pcm.c 2012-11-08 11:41:06.512420658 -0700 @@ -456,7 +456,7 @@ static int configure_endpoint(struct snd return ret; if (subs-sync_endpoint) - ret = snd_usb_endpoint_set_params(subs-data_endpoint, + ret = snd_usb_endpoint_set_params(subs-sync_endpoint, subs-pcm_format, subs-channels, subs-period_bytes, -- Jeffrey Barish -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov ___ 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 07.11.2012 00:54, Jeffrey Barish wrote: I guess that snd_usb_pcm_prepare is called by the core usb system to prepare the snd driver. Anyway, snd_usb_pcm_prepare calls configure_endpoint with a substream. Then configure_endpoint calls snd_usb_endpoint_set_params with the data endpoint that corresponds to the substream. snd_usb_endpoint_set_params calls data_ep_set_params with the data ep and data_ep_set_params sets nurbs to 2 for the data endpoint. snd_usb_endpoint_set_params has code to call sync_ep_set_params when the endpoint is type sync. sync_ep_set_params sets nurbs to 4 (why?). However, snd_usb_endpoint_set_params never invokes the call to sync_ep_set_params because ep-type is always data. Back up: snd_usb_endpoint_set_params is called from configure_endpoint. It is called from an if block contingent on the substream's having a sync endpoint. It does. However, the call to snd_usb_endpoint_set_params passes subs-data_endpoint as the first argument, so snd_usb_endpoint_set_params simply repeats the operations it performed as a result of the previous invocation. I presume that the first argument to the second call to snd_usb_endpoint_set_params should be subs-sync_endpoint. Eh. You clearly spotted a bug here. The rally interesting thing is that that it didn't bite us earlier, as it's in since 3.6. I made that change. Now freqm does change. However, I am getting tons of ticks. Now it sounds as if the payload size is always wrong. Oh, 44.1 kHz works. 48 kHz works. 88.2 and 96 don't work. That's a different issue. Would you like to prepare a patch for the issue above please? Thanks, Daniel -- 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 07.11.2012 10:01, Daniel Mack wrote: On 07.11.2012 00:54, Jeffrey Barish wrote: I guess that snd_usb_pcm_prepare is called by the core usb system to prepare the snd driver. Anyway, snd_usb_pcm_prepare calls configure_endpoint with a substream. Then configure_endpoint calls snd_usb_endpoint_set_params with the data endpoint that corresponds to the substream. snd_usb_endpoint_set_params calls data_ep_set_params with the data ep and data_ep_set_params sets nurbs to 2 for the data endpoint. snd_usb_endpoint_set_params has code to call sync_ep_set_params when the endpoint is type sync. sync_ep_set_params sets nurbs to 4 (why?). However, snd_usb_endpoint_set_params never invokes the call to sync_ep_set_params because ep-type is always data. Back up: snd_usb_endpoint_set_params is called from configure_endpoint. It is called from an if block contingent on the substream's having a sync endpoint. It does. However, the call to snd_usb_endpoint_set_params passes subs-data_endpoint as the first argument, so snd_usb_endpoint_set_params simply repeats the operations it performed as a result of the previous invocation. I presume that the first argument to the second call to snd_usb_endpoint_set_params should be subs-sync_endpoint. Eh. You clearly spotted a bug here. The rally interesting thing is that that it didn't bite us earlier, as it's in since 3.6. I made that change. Now freqm does change. However, I am getting tons of ticks. Now it sounds as if the payload size is always wrong. Oh, 44.1 kHz works. 48 kHz works. 88.2 and 96 don't work. That's a different issue. Would you like to prepare a patch for the issue above please? Thinking about it further, that could also explain the memory corruption we've revently seen in that driver ... -- 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 Wed 07 November 2012 10:04:14 Daniel Mack wrote: On 07.11.2012 10:01, Daniel Mack wrote: On 07.11.2012 00:54, Jeffrey Barish wrote: I guess that snd_usb_pcm_prepare is called by the core usb system to prepare the snd driver. Anyway, snd_usb_pcm_prepare calls configure_endpoint with a substream. Then configure_endpoint calls snd_usb_endpoint_set_params with the data endpoint that corresponds to the substream. snd_usb_endpoint_set_params calls data_ep_set_params with the data ep and data_ep_set_params sets nurbs to 2 for the data endpoint. snd_usb_endpoint_set_params has code to call sync_ep_set_params when the endpoint is type sync. sync_ep_set_params sets nurbs to 4 (why?). However, snd_usb_endpoint_set_params never invokes the call to sync_ep_set_params because ep-type is always data. Back up: snd_usb_endpoint_set_params is called from configure_endpoint. It is called from an if block contingent on the substream's having a sync endpoint. It does. However, the call to snd_usb_endpoint_set_params passes subs-data_endpoint as the first argument, so snd_usb_endpoint_set_params simply repeats the operations it performed as a result of the previous invocation. I presume that the first argument to the second call to snd_usb_endpoint_set_params should be subs-sync_endpoint. Eh. You clearly spotted a bug here. The rally interesting thing is that that it didn't bite us earlier, as it's in since 3.6. I made that change. Now freqm does change. However, I am getting tons of ticks. Now it sounds as if the payload size is always wrong. Oh, 44.1 kHz works. 48 kHz works. 88.2 and 96 don't work. That's a different issue. Would you like to prepare a patch for the issue above please? I don't know how to prepare a patch, so I'm inclined to fix the remaining problem before stopping to figure out the patch problem. I didn't get your previous email. I hope that it contained some suggestions on what to look for to solve the remaining problem. Please send it again. The problem seems to be related to timing considering that the driver works perfectly 5-10% of the time, but timing of what? I don't know what to look for. Thinking about it further, that could also explain the memory corruption we've revently seen in that driver ... -- Jeffrey Barish -- 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 Tue 06 November 2012 01:12:42 Daniel Mack wrote: 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 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 the background that interfered with the device driver. I removed or disabled all services that I could identify as superfluous. Removed services include zeitgeist, apparmor, modemmanager, mdadm, and bluetooth. Disabled services include atd, dns-clean, and
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 the background that interfered with the device driver. I removed or disabled all services that I could identify as superfluous. Removed services include zeitgeist, apparmor, modemmanager, mdadm, and bluetooth. Disabled services include atd, dns-clean, and pppd-dns. The system has been running perfectly with an 88.2 kHz sample rate and no external USB hub for 2 days. However, I tried booting the system with a copy of the OS from before I removed superfluous services. It still ran perfectly. Thus, I cannot convince
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 something to do with services running in the background that interfered with the device driver. I removed or disabled all services that I could identify as superfluous. Removed services include zeitgeist, apparmor, modemmanager, mdadm, and bluetooth. Disabled services include atd, dns-clean, and pppd-dns. The system has been running perfectly with an 88.2 kHz sample rate and no external USB hub for 2 days. However, I tried booting the system with a copy of the OS from before I removed superfluous services. It still ran perfectly. Thus, I cannot convince myself that removing superfluous services actually solved the problem.
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 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 the background that interfered with the device driver. I removed or disabled all services that I could identify as superfluous. Removed services include zeitgeist, apparmor, modemmanager, mdadm, and bluetooth. Disabled services include atd, dns-clean, and pppd-dns. The system has been running perfectly with an 88.2 kHz sample rate and no external USB hub for 2 days. However, I tried booting the system with a copy of the OS from before I removed superfluous services. It still
Re: [Alsa-user] Ticks when playing to USB DAC at high sample rates
[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 the background that interfered with the device driver. I removed or disabled all services that I could identify as superfluous. Removed services include zeitgeist, apparmor, modemmanager, mdadm, and bluetooth. Disabled services include atd, dns-clean, and pppd-dns. The system has been running perfectly with an 88.2 kHz sample rate and no external USB hub for 2 days. However, I tried booting the system with a copy of the OS from before I removed superfluous services. It still ran perfectly. Thus, I cannot convince myself that removing superfluous services actually solved the problem. I suppose it's possible that some service was running sporadically, which could explain why the
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 the background that interfered with the device driver. I removed or disabled all services that I could identify as superfluous. Removed services include zeitgeist, apparmor, modemmanager, mdadm, and bluetooth. Disabled services include atd, dns-clean, and pppd-dns. The system has been running perfectly with an 88.2 kHz sample rate and no external USB hub for 2 days. However, I tried booting the system with a copy of the OS from before I removed superfluous services. It still ran perfectly. Thus, I cannot convince
Re: [Alsa-user] Ticks when playing to USB DAC at high sample rates
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 the background that interfered with the device driver. I removed or disabled all services that I could identify as superfluous. Removed services include zeitgeist, apparmor, modemmanager, mdadm, and bluetooth. Disabled services include atd, dns-clean, and pppd-dns. The system has been running perfectly with an 88.2 kHz sample rate and no external USB hub for 2 days. However, I tried booting the system with a copy of the OS from before I removed superfluous services. It still ran perfectly. Thus, I cannot convince myself that removing superfluous services actually solved the problem. I suppose it's possible that
Re: [Alsa-user] Ticks when playing to USB DAC at high sample rates
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 the background that interfered with the device driver. I removed or disabled all services that I could identify as superfluous. Removed services include zeitgeist, apparmor, modemmanager, mdadm, and bluetooth. Disabled services include atd, dns-clean, and pppd-dns. The system has been running perfectly with an 88.2 kHz sample rate and no external USB hub for 2 days. However, I tried booting the system with a copy of the OS from before I removed superfluous services. It still ran perfectly. Thus, I cannot convince myself that removing superfluous services actually solved the problem. I suppose it's possible that
Re: [Alsa-user] Ticks when playing to USB DAC at high sample rates
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 the background that interfered with the device driver. I removed or disabled all services that I could identify as superfluous. Removed services include zeitgeist, apparmor, modemmanager, mdadm, and bluetooth. Disabled services include atd, dns-clean, and pppd-dns. The system has been running perfectly with an 88.2 kHz sample rate and no external USB hub for 2 days. However, I tried booting the system with a copy of the OS from before I removed superfluous services. It still ran perfectly. Thus, I cannot convince myself that removing superfluous services actually solved the problem. I suppose it's possible that
Re: [Alsa-user] Ticks when playing to USB DAC at high sample rates
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. -- Jeffrey Barish -- WINDOWS 8 is here. Millions of people. Your app in 30 days. Visit The Windows 8 Center at Sourceforge for all your go to resources. http://windows8center.sourceforge.net/ join-generation-app-and-make-money-coding-fast/ ___ 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 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'? -- WINDOWS 8 is here. Millions of people. Your app in 30 days. Visit The Windows 8 Center at Sourceforge for all your go to resources. http://windows8center.sourceforge.net/ join-generation-app-and-make-money-coding-fast/ ___ 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 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'? Most recently, with the kernel you just had me build (3.7.0), but I have heard them previously with every kernel I have tried (3.6.2 and 3.2.0). -- Jeffrey Barish -- WINDOWS 8 is here. Millions of people. Your app in 30 days. Visit The Windows 8 Center at Sourceforge for all your go to resources. http://windows8center.sourceforge.net/ join-generation-app-and-make-money-coding-fast/ ___ 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 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. -- Jeffrey Barish -- WINDOWS 8 is here. Millions of people. Your app in 30 days. Visit The Windows 8 Center at Sourceforge for all your go to resources. http://windows8center.sourceforge.net/ join-generation-app-and-make-money-coding-fast/ ___ 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 Wed 17 October 2012 01:04:13 Daniel Mack wrote: On Oct 16, 2012 11:29 PM, Jeffrey Barish jeff_bar...@earthlink.net wrote: On Fri 28 September 2012 10:37:01 Daniel Mack wrote: On 28.09.2012 04:55, Jeffrey Barish wrote: On Fri 28 September 2012 03:06:22 Daniel Mack wrote: (adding back the mailing list - please don't drop it in replies) Oops. My bad. On 28.09.2012 02:43, Jeffrey Barish wrote: On Fri 28 September 2012 02:02:05 you wrote: On 28.09.2012 01:56, Jeffrey Barish wrote: I am using a USB DAC (HRT Music Streamer II) which operates in asynchronous mode. It works perfectly at sample rates up to 48 kHz. When I go to 88.2 or 96, it works perfectly sometimes. Most of the time I get ticks. When it starts playing without ticks, it will continue to play without ticks to the end of the track. A different USB DAC that operates in isochronous mode is able to play at the high sample rates without problem. Which kernel are you on? And please post the output of 'lsusb -v'. I am on the latest kernel, 3.2.0-31-generic That is not the latest kernel - we're currently close to the final version of 3.6, and the snd-usb driver has seen major overhaul in the last versions. So it would be interesting to know whether you see these effects when running a kernel built from this git: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Daniel You seem to have me confused with someone who knows what he's doing. I meant that 3.2.0-31-generic was the latest kernel available from Ubuntu. You're proposing what sounds like a worthwhile experiment considering the major overhaul to the snd-usb driver, but I've never upgraded a kernel except from deb packages, so I'm quaking in my boots just thinking about it. Ooh, and I bet you're telling me that I would have to make the kernel. More quaking. You could as well just wait for the next ppa kernel and install that one form the package once it's there. http://kernel.ubuntu.com/~kernel-ppa/mainline/ There was unfortunately one small regression in the last versions that I just fixed, so be sure to wait for one more packaged release or even for 3.6-final. Out of curiousity, are you aware of any specific characteristics of the old snd-usb driver that could account for what I am experiencing? No, but it would be way easier to have a look into that if it also happens with the current version :) Daniel Kernel 3.6.2-quantal does the same thing. When I interpose a USB hub between the computer and the USB DAC, the ticks go away. Playback works perfectly at 96 kHz. However, at 88.2 kHz, I now get occasional blips (instead of steady ticks). These symptoms point to excessive delay in the control feedback loop, probably because of buffers in the driver that are too big. If I wanted to take a look at the source code for the driver to see whether I can find anything, where would I find it? Here: http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=tree;f=sound/usb Please don't hessitate to share any patches or questions. 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, 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. Jeff-- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct___ 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 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 -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ 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 Fri 28 September 2012 10:37:01 Daniel Mack wrote: On 28.09.2012 04:55, Jeffrey Barish wrote: On Fri 28 September 2012 03:06:22 Daniel Mack wrote: (adding back the mailing list - please don't drop it in replies) Oops. My bad. On 28.09.2012 02:43, Jeffrey Barish wrote: On Fri 28 September 2012 02:02:05 you wrote: On 28.09.2012 01:56, Jeffrey Barish wrote: I am using a USB DAC (HRT Music Streamer II) which operates in asynchronous mode. It works perfectly at sample rates up to 48 kHz. When I go to 88.2 or 96, it works perfectly sometimes. Most of the time I get ticks. When it starts playing without ticks, it will continue to play without ticks to the end of the track. A different USB DAC that operates in isochronous mode is able to play at the high sample rates without problem. Which kernel are you on? And please post the output of 'lsusb -v'. I am on the latest kernel, 3.2.0-31-generic That is not the latest kernel - we're currently close to the final version of 3.6, and the snd-usb driver has seen major overhaul in the last versions. So it would be interesting to know whether you see these effects when running a kernel built from this git: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Daniel You seem to have me confused with someone who knows what he's doing. I meant that 3.2.0-31-generic was the latest kernel available from Ubuntu. You're proposing what sounds like a worthwhile experiment considering the major overhaul to the snd-usb driver, but I've never upgraded a kernel except from deb packages, so I'm quaking in my boots just thinking about it. Ooh, and I bet you're telling me that I would have to make the kernel. More quaking. You could as well just wait for the next ppa kernel and install that one form the package once it's there. http://kernel.ubuntu.com/~kernel-ppa/mainline/ There was unfortunately one small regression in the last versions that I just fixed, so be sure to wait for one more packaged release or even for 3.6-final. Out of curiousity, are you aware of any specific characteristics of the old snd-usb driver that could account for what I am experiencing? No, but it would be way easier to have a look into that if it also happens with the current version :) Daniel Kernel 3.6.2-quantal does the same thing. When I interpose a USB hub between the computer and the USB DAC, the ticks go away. Playback works perfectly at 96 kHz. However, at 88.2 kHz, I now get occasional blips (instead of steady ticks). These symptoms point to excessive delay in the control feedback loop, probably because of buffers in the driver that are too big. If I wanted to take a look at the source code for the driver to see whether I can find anything, where would I find it? -- Jeffrey Barish -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ 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 Oct 16, 2012 11:29 PM, Jeffrey Barish jeff_bar...@earthlink.net wrote: On Fri 28 September 2012 10:37:01 Daniel Mack wrote: On 28.09.2012 04:55, Jeffrey Barish wrote: On Fri 28 September 2012 03:06:22 Daniel Mack wrote: (adding back the mailing list - please don't drop it in replies) Oops. My bad. On 28.09.2012 02:43, Jeffrey Barish wrote: On Fri 28 September 2012 02:02:05 you wrote: On 28.09.2012 01:56, Jeffrey Barish wrote: I am using a USB DAC (HRT Music Streamer II) which operates in asynchronous mode. It works perfectly at sample rates up to 48 kHz. When I go to 88.2 or 96, it works perfectly sometimes. Most of the time I get ticks. When it starts playing without ticks, it will continue to play without ticks to the end of the track. A different USB DAC that operates in isochronous mode is able to play at the high sample rates without problem. Which kernel are you on? And please post the output of 'lsusb -v'. I am on the latest kernel, 3.2.0-31-generic That is not the latest kernel - we're currently close to the final version of 3.6, and the snd-usb driver has seen major overhaul in the last versions. So it would be interesting to know whether you see these effects when running a kernel built from this git: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Daniel You seem to have me confused with someone who knows what he's doing. I meant that 3.2.0-31-generic was the latest kernel available from Ubuntu. You're proposing what sounds like a worthwhile experiment considering the major overhaul to the snd-usb driver, but I've never upgraded a kernel except from deb packages, so I'm quaking in my boots just thinking about it. Ooh, and I bet you're telling me that I would have to make the kernel. More quaking. You could as well just wait for the next ppa kernel and install that one form the package once it's there. http://kernel.ubuntu.com/~kernel-ppa/mainline/ There was unfortunately one small regression in the last versions that I just fixed, so be sure to wait for one more packaged release or even for 3.6-final. Out of curiousity, are you aware of any specific characteristics of the old snd-usb driver that could account for what I am experiencing? No, but it would be way easier to have a look into that if it also happens with the current version :) Daniel Kernel 3.6.2-quantal does the same thing. When I interpose a USB hub between the computer and the USB DAC, the ticks go away. Playback works perfectly at 96 kHz. However, at 88.2 kHz, I now get occasional blips (instead of steady ticks). These symptoms point to excessive delay in the control feedback loop, probably because of buffers in the driver that are too big. If I wanted to take a look at the source code for the driver to see whether I can find anything, where would I find it? Here: http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=tree;f=sound/usb Please don't hessitate to share any patches or questions. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct___ 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 28.09.2012 04:55, Jeffrey Barish wrote: On Fri 28 September 2012 03:06:22 Daniel Mack wrote: (adding back the mailing list - please don't drop it in replies) Oops. My bad. On 28.09.2012 02:43, Jeffrey Barish wrote: On Fri 28 September 2012 02:02:05 you wrote: On 28.09.2012 01:56, Jeffrey Barish wrote: I am using a USB DAC (HRT Music Streamer II) which operates in asynchronous mode. It works perfectly at sample rates up to 48 kHz. When I go to 88.2 or 96, it works perfectly sometimes. Most of the time I get ticks. When it starts playing without ticks, it will continue to play without ticks to the end of the track. A different USB DAC that operates in isochronous mode is able to play at the high sample rates without problem. Which kernel are you on? And please post the output of 'lsusb -v'. I am on the latest kernel, 3.2.0-31-generic That is not the latest kernel - we're currently close to the final version of 3.6, and the snd-usb driver has seen major overhaul in the last versions. So it would be interesting to know whether you see these effects when running a kernel built from this git: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Daniel You seem to have me confused with someone who knows what he's doing. I meant that 3.2.0-31-generic was the latest kernel available from Ubuntu. You're proposing what sounds like a worthwhile experiment considering the major overhaul to the snd-usb driver, but I've never upgraded a kernel except from deb packages, so I'm quaking in my boots just thinking about it. Ooh, and I bet you're telling me that I would have to make the kernel. More quaking. You could as well just wait for the next ppa kernel and install that one form the package once it's there. http://kernel.ubuntu.com/~kernel-ppa/mainline/ There was unfortunately one small regression in the last versions that I just fixed, so be sure to wait for one more packaged release or even for 3.6-final. Out of curiousity, are you aware of any specific characteristics of the old snd-usb driver that could account for what I am experiencing? No, but it would be way easier to have a look into that if it also happens with the current version :) Daniel -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
[Alsa-user] Ticks when playing to USB DAC at high sample rates
I am using a USB DAC (HRT Music Streamer II) which operates in asynchronous mode. It works perfectly at sample rates up to 48 kHz. When I go to 88.2 or 96, it works perfectly sometimes. Most of the time I get ticks. When it starts playing without ticks, it will continue to play without ticks to the end of the track. A different USB DAC that operates in isochronous mode is able to play at the high sample rates without problem. The designer of the HRT DAC (who provides excellent support, by the way) believes that the problem might be buffer underrun. Considering that the problem occurs only at high sample rates, I can see some logic in that theory. However, what I don't see is why playback works perfectly all the way to the end of a track whenever it starts perfectly. If the problem were an underrun, I would expect that at least occasionally the buffer would underrun after a perfect start and I would start hearing ticks midway through a track. Never happens. Moreover, I would not be surprised were the ticks to vanish sometimes after a faulty start when the computer finally catches up. Also never happens. Still, assuming that the problem has something to do with the speed of the platform, I tried exiting the desktop to reduce the load on the CPU (which, by the way, has two cores that operate at 3.1 GHz). No joy. I also found that the ticks occur just by synthesizing a sine wave using gst- launch: gst-launch -v audiotestsrc volume=0.01 ! audio/x-raw-float, width=64, rate=96000, channels=2, endianness=1234 ! audioconvert ! alsasink The player uses GStreamer too, so maybe the problem is with GStreamer, not alsa. So I tried a different player (sox). To play the track with sox, I converted it first to wav. I still get ticks. Any suggestions? Has anyone gotten any asynchronous USB DAC to work at sample rates of 88.2 or 96 kHz? In case it matters, I am running Lubuntu 12.04. -- Jeffrey Barish -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html___ 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 28.09.2012 01:56, Jeffrey Barish wrote: I am using a USB DAC (HRT Music Streamer II) which operates in asynchronous mode. It works perfectly at sample rates up to 48 kHz. When I go to 88.2 or 96, it works perfectly sometimes. Most of the time I get ticks. When it starts playing without ticks, it will continue to play without ticks to the end of the track. A different USB DAC that operates in isochronous mode is able to play at the high sample rates without problem. Which kernel are you on? And please post the output of 'lsusb -v'. Thanks, Daniel The designer of the HRT DAC (who provides excellent support, by the way) believes that the problem might be buffer underrun. Considering that the problem occurs only at high sample rates, I can see some logic in that theory. However, what I don't see is why playback works perfectly all the way to the end of a track whenever it starts perfectly. If the problem were an underrun, I would expect that at least occasionally the buffer would underrun after a perfect start and I would start hearing ticks midway through a track. Never happens. Moreover, I would not be surprised were the ticks to vanish sometimes after a faulty start when the computer finally catches up. Also never happens. Still, assuming that the problem has something to do with the speed of the platform, I tried exiting the desktop to reduce the load on the CPU (which, by the way, has two cores that operate at 3.1 GHz). No joy. I also found that the ticks occur just by synthesizing a sine wave using gst-launch: gst-launch -v audiotestsrc volume=0.01 ! audio/x-raw-float, width=64, rate=96000, channels=2, endianness=1234 ! audioconvert ! alsasink The player uses GStreamer too, so maybe the problem is with GStreamer, not alsa. So I tried a different player (sox). To play the track with sox, I converted it first to wav. I still get ticks. Any suggestions? Has anyone gotten any asynchronous USB DAC to work at sample rates of 88.2 or 96 kHz? In case it matters, I am running Lubuntu 12.04. -- Jeffrey Barish -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ 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
(adding back the mailing list - please don't drop it in replies) On 28.09.2012 02:43, Jeffrey Barish wrote: On Fri 28 September 2012 02:02:05 you wrote: On 28.09.2012 01:56, Jeffrey Barish wrote: I am using a USB DAC (HRT Music Streamer II) which operates in asynchronous mode. It works perfectly at sample rates up to 48 kHz. When I go to 88.2 or 96, it works perfectly sometimes. Most of the time I get ticks. When it starts playing without ticks, it will continue to play without ticks to the end of the track. A different USB DAC that operates in isochronous mode is able to play at the high sample rates without problem. Which kernel are you on? And please post the output of 'lsusb -v'. I am on the latest kernel, 3.2.0-31-generic That is not the latest kernel - we're currently close to the final version of 3.6, and the snd-usb driver has seen major overhaul in the last versions. So it would be interesting to know whether you see these effects when running a kernel built from this git: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Daniel -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ 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 Fri 28 September 2012 03:06:22 Daniel Mack wrote: (adding back the mailing list - please don't drop it in replies) Oops. My bad. On 28.09.2012 02:43, Jeffrey Barish wrote: On Fri 28 September 2012 02:02:05 you wrote: On 28.09.2012 01:56, Jeffrey Barish wrote: I am using a USB DAC (HRT Music Streamer II) which operates in asynchronous mode. It works perfectly at sample rates up to 48 kHz. When I go to 88.2 or 96, it works perfectly sometimes. Most of the time I get ticks. When it starts playing without ticks, it will continue to play without ticks to the end of the track. A different USB DAC that operates in isochronous mode is able to play at the high sample rates without problem. Which kernel are you on? And please post the output of 'lsusb -v'. I am on the latest kernel, 3.2.0-31-generic That is not the latest kernel - we're currently close to the final version of 3.6, and the snd-usb driver has seen major overhaul in the last versions. So it would be interesting to know whether you see these effects when running a kernel built from this git: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Daniel You seem to have me confused with someone who knows what he's doing. I meant that 3.2.0-31-generic was the latest kernel available from Ubuntu. You're proposing what sounds like a worthwhile experiment considering the major overhaul to the snd-usb driver, but I've never upgraded a kernel except from deb packages, so I'm quaking in my boots just thinking about it. Ooh, and I bet you're telling me that I would have to make the kernel. More quaking. Out of curiousity, are you aware of any specific characteristics of the old snd-usb driver that could account for what I am experiencing? Thanks for your suggestion. I will investigate further tomorrow. -- Jeffrey Barish -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
