Re: [Alsa-user] Status of CM6631 USB
On Thu, Apr 11, 2013 at 12:20:39 -0700, chris hermansen wrote: First time: I plugged the Schiit USB into the laptop before booting the laptop (only one altset for output, two for input for stream0) Second time: I hot-plugged the Schiit USB into the already running laptop (two altsets for stream0, correct behaviour) Third time: I rebooted the laptop after the second time above without unplugging the Schiit (two altsets for stream0, correct behaviour) Fourth time: I halted the laptop, unplugged and replugged the Schiit, booted (only one altset, both output and capture, for stream0). I can try some repeatability testing on these if you like. If this is repeatable, is seems like the behavior depends on USB power management as well. Or some other difference between cold boot and restart / boot without USB power loss. It doesn't complain about clock source validity for altsetting two during cold boot like it does when you plug in the USB while the laptop is running. So the log messages and the behavior is opposite of what I would expect. It either never even tries to initialize altsetting two during cold boot or fails before the clock source validation. In the latter case you should have gotten some more dmesg errors. You could try to recompile with CONFIG_SND_DEBUG and CONFIG_SND_DEBUG_VERBOSE enabled, to get some more debug output. Torstein -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] Status of CM6631 USB
On Wed, Apr 10, 2013 at 08:46:04 -0700, chris hermansen wrote: Torstein and list: Wait! this is still weird. Please see at bottom... On Wed, Apr 10, 2013 at 8:31 AM, chris hermansen clherman...@gmail.com wrote: Torstein, list: On Wed, Apr 10, 2013 at 2:32 AM, Torstein Hegge he...@resisty.net wrote: What does dmesg / /var/log/kern.log say when you plug in the device with the v3.9-rc6 kernel? Hmm things are getting interesting. Yesterday, when I had the problem with missing altset 2, as far as I can remember, I had plugged in the Schiit before booting and switched the Schiit to USB once booted. Today below I booted the machine, switched the Schiit to usb input, started up a terminal window, checked the kernel version, tailed the /var/log/kern.log, plugged the Schiit in, then checked the /proc/asound/Interface/stream0 file. Despite the error messages when plugging, it seems I have altset 2 back! [...] I tried to replicate the same conditions as previously, ie plug before boot, but now I seem to have the altset 2 back. I tried playing a few tracks at different speeds / bit rates and all seems fine now, ie the 24 bit files get converted to 32 bit and not 16 bit on altset 2. It would be fantastic to consider this fixed but I'm a bit lost as to how my altset disappeared for a session... After I sent this, I got to thinking, maybe I did not re-plug the Schitt while the machine was off... so: I shut down the machine, unplugged the Schiit, switched it to TOSLINK, plugged the USB back in, and rebooted. At this point I have not yet switched the Schiit back to USB, but what I have in /proc/asound/Interface/stream0 is now: clh@temuko:~$ cat /proc/asound/Interface/stream0 CMEDIA Schiit USB Interface at usb-:00:13.2-3, high speed : USB Audio Playback: Status: Stop Interface 1 Altset 1 Format: S16_LE Channels: 2 Endpoint: 5 OUT (ASYNC) Rates: 44100, 48000, 88200, 96000, 192000 Data packet interval: 125 us Capture: Status: Stop Interface 4 Altset 1 Format: S16_LE Channels: 2 Endpoint: 8 IN (ASYNC) Rates: 44100, 48000, 88200, 96000, 192000 Data packet interval: 125 us clh@temuko:~$ ie no S32_LE altset on either playback or capture. Switching the Schiit back to USB does not change this. The USB or S/PDIF input setting on the Schiit shouldn't affect the behavior of the USB interface, it just selects the DAC source. But I don't quite follow what you did different between your tests. Plugging in after boot works fine. Keeping the USB plugged in over a reboot works fine. Plugging in the USB while the laptop is off and then booting gives a missing alternate setting? Or did I get those last two mixed up? Torstein -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] Status of CM6631 USB
Torstein, list; On Thu, Apr 11, 2013 at 2:02 AM, Torstein Hegge he...@resisty.net wrote: [...] ie no S32_LE altset on either playback or capture. Switching the Schiit back to USB does not change this. The USB or S/PDIF input setting on the Schiit shouldn't affect the behavior of the USB interface, it just selects the DAC source. I am pretty sure you are correct but I wanted to make sure that there wasn't some kind of signalling that happened when I switched the active input to the USB. But I don't quite follow what you did different between your tests. Plugging in after boot works fine. Keeping the USB plugged in over a reboot works fine. Plugging in the USB while the laptop is off and then booting gives a missing alternate setting? Or did I get those last two mixed up? Sorry for the lack of clarity! First time: I plugged the Schiit USB into the laptop before booting the laptop (only one altset for output, two for input for stream0) Second time: I hot-plugged the Schiit USB into the already running laptop (two altsets for stream0, correct behaviour) Third time: I rebooted the laptop after the second time above without unplugging the Schiit (two altsets for stream0, correct behaviour) Fourth time: I halted the laptop, unplugged and replugged the Schiit, booted (only one altset, both output and capture, for stream0). I can try some repeatability testing on these if you like. -- Chris Hermansen · clhermansen at gmail dot com C'est ma façon de parler. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] Status of CM6631 USB
Torstein and list: Wait! this is still weird. Please see at bottom... On Wed, Apr 10, 2013 at 8:31 AM, chris hermansen clherman...@gmail.com wrote: Torstein, list: On Wed, Apr 10, 2013 at 2:32 AM, Torstein Hegge he...@resisty.net wrote: [...] What does dmesg / /var/log/kern.log say when you plug in the device with the v3.9-rc6 kernel? Hmm things are getting interesting. Yesterday, when I had the problem with missing altset 2, as far as I can remember, I had plugged in the Schiit before booting and switched the Schiit to USB once booted. Today below I booted the machine, switched the Schiit to usb input, started up a terminal window, checked the kernel version, tailed the /var/log/kern.log, plugged the Schiit in, then checked the /proc/asound/Interface/stream0 file. Despite the error messages when plugging, it seems I have altset 2 back! clh@temuko:~$ uname -r 3.9.0-030900rc6-generic clh@temuko:~$ tail -f /var/log/kern.log Apr 10 08:08:39 temuko kernel: [ 21.818692] 8139too :02:03.0 eth0: link down Apr 10 08:08:39 temuko kernel: [ 21.818776] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready Apr 10 08:08:44 temuko kernel: [ 26.130144] wlan0: authenticate with 20:76:00:0d:dd:00 Apr 10 08:08:44 temuko kernel: [ 26.135889] wlan0: send auth to 20:76:00:0d:dd:00 (try 1/3) Apr 10 08:08:44 temuko kernel: [ 26.137723] wlan0: authenticated Apr 10 08:08:44 temuko kernel: [ 26.138252] ath5k :02:02.0 wlan0: disabling HT/VHT due to WEP/TKIP use Apr 10 08:08:44 temuko kernel: [ 26.140071] wlan0: associate with 20:76:00:0d:dd:00 (try 1/3) Apr 10 08:08:44 temuko kernel: [ 26.142175] wlan0: RX AssocResp from 20:76:00:0d:dd:00 (capab=0x411 status=0 aid=3) Apr 10 08:08:44 temuko kernel: [ 26.142630] wlan0: associated Apr 10 08:08:44 temuko kernel: [ 26.142702] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready (here I am plugging in the Schiit) Apr 10 08:11:15 temuko kernel: [ 177.148055] usb 1-3: new high-speed USB device number 2 using ehci-pci Apr 10 08:11:15 temuko kernel: [ 177.305718] usb 1-3: config 1 interface 8 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64 Apr 10 08:11:15 temuko kernel: [ 177.305731] usb 1-3: config 1 interface 8 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64 Apr 10 08:11:15 temuko kernel: [ 177.308176] usb 1-3: New USB device found, idVendor=0d8c, idProduct=0304 Apr 10 08:11:15 temuko kernel: [ 177.308187] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Apr 10 08:11:15 temuko kernel: [ 177.308197] usb 1-3: Product: Schiit USB Interface Apr 10 08:11:15 temuko kernel: [ 177.308206] usb 1-3: Manufacturer: CMEDIA Apr 10 08:11:15 temuko kernel: [ 177.694819] hidraw: raw HID events driver (C) Jiri Kosina Apr 10 08:11:15 temuko kernel: [ 177.712517] 2:1:2: clock source 15 is not valid, cannot use Apr 10 08:11:15 temuko kernel: [ 177.743525] 2:2:2: clock source 16 is not valid, cannot use Apr 10 08:11:15 temuko kernel: [ 177.784388] 2:5:1: clock source 19 is not valid, cannot use Apr 10 08:11:15 temuko kernel: [ 177.788307] 2:5:2: clock source 19 is not valid, cannot use Apr 10 08:11:15 temuko kernel: [ 177.788858] cannot get ctl value: req = 0x83, wValue = 0x201, wIndex = 0x0, type = 4 Apr 10 08:11:15 temuko kernel: [ 177.791363] usbcore: registered new interface driver snd-usb-audio Apr 10 08:11:15 temuko kernel: [ 177.849874] usbcore: registered new interface driver usbhid Apr 10 08:11:15 temuko kernel: [ 177.849886] usbhid: USB HID core driver Apr 10 08:11:15 temuko kernel: [ 177.897234] input: CMEDIA Schiit USB Interface as /devices/pci:00/:00:13.2/usb1/1-3/1-3:1.6/input/input7 Apr 10 08:11:15 temuko kernel: [ 177.897944] hid-generic 0003:0D8C:0304.0001: input,hidraw0: USB HID v1.00 Device [CMEDIA Schiit USB Interface] on usb-:00:13.2-3/input6 (ok that's all it's going to do I guess) ^C clh@temuko:~$ ls /proc/asound/Interface id midi0 pcm0c pcm0p pcm1c pcm1p pcm2p pcm3c stream0 stream1 stream2 stream3 usbbus usbid usbmixer clh@temuko:~$ cat !$/stream0 cat /proc/asound/Interface/stream0 CMEDIA Schiit USB Interface at usb-:00:13.2-3, high speed : USB Audio Playback: Status: Stop Interface 1 Altset 1 Format: S16_LE Channels: 2 Endpoint: 5 OUT (ASYNC) Rates: 44100, 48000, 88200, 96000, 192000 Data packet interval: 125 us Interface 1 Altset 2 Format: S32_LE Channels: 2 Endpoint: 5 OUT (ASYNC) Rates: 44100, 48000, 88200, 96000, 192000 Data packet interval: 125 us Capture: Status: Stop Interface 4 Altset 1 Format: S16_LE Channels: 2 Endpoint: 8 IN (ASYNC) Rates: 44100, 48000, 88200, 96000, 192000 Data packet interval: 125 us Interface 4 Altset 2 Format: S32_LE Channels: 2 Endpoint: 8 IN (ASYNC) Rates: 44100, 48000, 88200, 96000, 192000 Data packet interval: 125
Re: [Alsa-user] Status of CM6631 USB
On Mon, Apr 08, 2013 at 18:28:30 -0700, chris hermansen wrote: Torstein and list; On Mon, Mar 18, 2013 at 12:56 PM, chris hermansen clherman...@gmail.com wrote: Torstein and list; On Mar 18, 2013 12:52 PM, Torstein Hegge he...@resisty.net wrote: On Sun, Mar 17, 2013 at 07:36:01PM -0700, chris hermansen wrote: The kernel's compiled and I'm testing. Cutting to the chase, I can't seem to get it to misbehave any more. I'm a bit worried that you didn't get a single warning about runtime rate being different from current rate, if this last change is all that is needed, you should still get the warnings, followed by a reset. Torstein, I think you might have it nailed here. On behalf of us Schiit owners let me offer you a huge huge thank you for your patience and debugging here. I can't do any more testing for the next two weeks as I will be away (not in the same country as the Schiit and the old Toshiba). But I can pick up again in early April if there's more to do. OK, thank you for testing this. I will test more when I return on 30 April to see if I can observe the recovery sequence. Hmm that was a bit of a slip of the brain. Anyway, I'm actually back in the same general vicinity as the Bifrost and can do some more testing. Torstein, is there anything specific you want me to try, or just patch up the kernel and have at it? The latest iteration of the patch is included in the 3.9-rc6 kernel. You can try a plain 3.9-rc6 kernel without any modifications. Torstein -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] Status of CM6631 USB
Torstein, list; On Tue, Apr 9, 2013 at 12:34 AM, Torstein Hegge he...@resisty.net wrote: On Mon, Apr 08, 2013 at 18:28:30 -0700, chris hermansen wrote: [..] Hmm that was a bit of a slip of the brain. Anyway, I'm actually back in the same general vicinity as the Bifrost and can do some more testing. Torstein, is there anything specific you want me to try, or just patch up the kernel and have at it? The latest iteration of the patch is included in the 3.9-rc6 kernel. You can try a plain 3.9-rc6 kernel without any modifications. So, I've updated my aging Toshiba test bed to the latest Ubuntu 13.04 release and grabbed the 3.9-rc6 kernel from http://kernel.ubuntu.com for testing. Trying out a bunch of songs with no noise, that's great news! But now something else seems weird. When I play a 96/24 file through plughw corresponding to the Schiit, I see this: sudo aplay -vD plughw:CARD=Interface,DEV=0 2L* [sudo] password for clh: Home directory not accessible: Permission denied Playing WAVE '2L50SACD_tr1_96k_stereo.wav' : Signed 24 bit Little Endian in 3bytes, Rate 96000 Hz, Stereo Plug PCM: Linear conversion PCM (S16_LE) Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S24_3LE subformat: STD channels : 2 rate : 96000 exact rate : 96000 (96000/1) msbits : 24 buffer_size : 48000 period_size : 12000 period_time : 125000 tstamp_mode : NONE period_step : 1 avail_min: 12000 period_event : 0 start_threshold : 48000 stop_threshold : 48000 silence_threshold: 0 silence_size : 0 boundary : 1572864000 Slave: Hardware PCM card 1 'Schiit USB Interface' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : MMAP_INTERLEAVED format : S16_LE subformat: STD channels : 2 rate : 96000 exact rate : 96000 (96000/1) msbits : 16 buffer_size : 48000 period_size : 12000 period_time : 125000 tstamp_mode : NONE period_step : 1 avail_min: 12000 period_event : 0 start_threshold : 48000 stop_threshold : 48000 silence_threshold: 0 silence_size : 0 boundary : 1572864000 appl_ptr : 0 hw_ptr : 0 ^CAborted by signal Interrupt... Ie the 24bit data is getting downsampled to 16 bits! It also seems like stream0 for the Schiit only plays back 16bit data cat stream0 CMEDIA Schiit USB Interface at usb-:00:13.2-3, high speed : USB Audio Playback: Status: Stop Interface 1 Altset 1 Format: S16_LE Channels: 2 Endpoint: 5 OUT (ASYNC) Rates: 44100, 48000, 88200, 96000, 192000 Data packet interval: 125 us Capture: Status: Stop Interface 4 Altset 1 Format: S16_LE Channels: 2 Endpoint: 8 IN (ASYNC) Rates: 44100, 48000, 88200, 96000, 192000 Data packet interval: 125 us Interface 4 Altset 2 Format: S32_LE Channels: 2 Endpoint: 8 IN (ASYNC) Rates: 44100, 48000, 88200, 96000, 192000 Data packet interval: 125 us whereas stream1 shows both a 16 and 32 bit capability cat stream1 CMEDIA Schiit USB Interface at usb-:00:13.2-3, high speed : USB Audio #1 Playback: Status: Stop Interface 2 Altset 1 Format: S16_LE Channels: 2 Endpoint: 6 OUT (ASYNC) Rates: 44100, 48000, 88200, 96000, 176400, 192000 Data packet interval: 125 us Interface 2 Altset 2 Format: S32_LE Channels: 2 Endpoint: 6 OUT (ASYNC) Rates: 44100, 48000, 88200, 96000, 176400, 192000 Data packet interval: 125 us Capture: Status: Stop Interface 3 Altset 1 Format: S16_LE Channels: 2 Endpoint: 9 IN (ASYNC) Rates: 44100, 48000, 88200, 96000, 192000 Data packet interval: 125 us Interface 3 Altset 2 Format: S32_LE Channels: 2 Endpoint: 9 IN (ASYNC) Rates: 44100, 48000, 88200, 96000, 192000 Data packet interval: 125 us The problem is, stream1 and higher don't seem to be connected to the rest of the DAC. Also this stream0 looks markedly different than the version I displayed back on 3 March. Help? -- Chris Hermansen · clhermansen at gmail dot com C'est ma façon de parler. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] Status of CM6631 USB
Torstein and list; On Mon, Mar 18, 2013 at 12:56 PM, chris hermansen clherman...@gmail.com wrote: Torstein and list; On Mar 18, 2013 12:52 PM, Torstein Hegge he...@resisty.net wrote: On Sun, Mar 17, 2013 at 07:36:01PM -0700, chris hermansen wrote: The kernel's compiled and I'm testing. Cutting to the chase, I can't seem to get it to misbehave any more. I'm a bit worried that you didn't get a single warning about runtime rate being different from current rate, if this last change is all that is needed, you should still get the warnings, followed by a reset. Torstein, I think you might have it nailed here. On behalf of us Schiit owners let me offer you a huge huge thank you for your patience and debugging here. I can't do any more testing for the next two weeks as I will be away (not in the same country as the Schiit and the old Toshiba). But I can pick up again in early April if there's more to do. OK, thank you for testing this. I will test more when I return on 30 April to see if I can observe the recovery sequence. Hmm that was a bit of a slip of the brain. Anyway, I'm actually back in the same general vicinity as the Bifrost and can do some more testing. Torstein, is there anything specific you want me to try, or just patch up the kernel and have at it? -- Chris Hermansen · clhermansen at gmail dot com C'est ma façon de parler. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] Status of CM6631 USB
On Sun, Mar 17, 2013 at 07:36:01PM -0700, chris hermansen wrote: The kernel's compiled and I'm testing. Cutting to the chase, I can't seem to get it to misbehave any more. I'm a bit worried that you didn't get a single warning about runtime rate being different from current rate, if this last change is all that is needed, you should still get the warnings, followed by a reset. Torstein, I think you might have it nailed here. On behalf of us Schiit owners let me offer you a huge huge thank you for your patience and debugging here. I can't do any more testing for the next two weeks as I will be away (not in the same country as the Schiit and the old Toshiba). But I can pick up again in early April if there's more to do. OK, thank you for testing this. Torstein -- 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_mar ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] Status of CM6631 USB
Torstein and list; On Mar 18, 2013 12:52 PM, Torstein Hegge he...@resisty.net wrote: On Sun, Mar 17, 2013 at 07:36:01PM -0700, chris hermansen wrote: The kernel's compiled and I'm testing. Cutting to the chase, I can't seem to get it to misbehave any more. I'm a bit worried that you didn't get a single warning about runtime rate being different from current rate, if this last change is all that is needed, you should still get the warnings, followed by a reset. Torstein, I think you might have it nailed here. On behalf of us Schiit owners let me offer you a huge huge thank you for your patience and debugging here. I can't do any more testing for the next two weeks as I will be away (not in the same country as the Schiit and the old Toshiba). But I can pick up again in early April if there's more to do. OK, thank you for testing this. I will test more when I return on 30 April to see if I can observe the recovery sequence. -- 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_mar___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] Status of CM6631 USB
On Thu, Mar 14, 2013 at 10:13:17AM +0100, Torstein Hegge wrote:
If we can find some other explanation for the 'cannot get freq' and the
large negative rate you saw earlier, it might help to replace the
if (cur_rate != prev_rate) {
with
if (rate != prev_rate) {
so that we do the reset if the target rate is different from the
previous rate, ignoring what the device thinks its current rate is.
I had another look at the logs. If we choose to selectively ignore the
'cannot get freq', the other problems occurred directly after a missing
reset due to the device not reporting the just set rate when reading
back the rate. I think this is worth trying.
diff --git a/sound/usb/clock.c b/sound/usb/clock.c
index 746ec9b..68e1ac3 100644
--- a/sound/usb/clock.c
+++ b/sound/usb/clock.c
@@ -311,7 +311,7 @@ static int set_sample_rate_v2(struct snd_usb_audio *chip,
int iface,
/* Some devices doesn't respond to sample rate changes while the
* interface is active. */
- if (cur_rate != prev_rate) {
+ if (rate != prev_rate) {
switch (chip-usb_id) {
/* C-Media CM6610/CM6620/CM6631 */
case USB_ID(0x054c, 0x06cf): /* Sony */
Torstein
--
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_mar
___
Alsa-user mailing list
Alsa-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] Status of CM6631 USB
Torstein and list;
On Sun, Mar 17, 2013 at 5:31 AM, Torstein Hegge he...@resisty.net wrote:
On Thu, Mar 14, 2013 at 10:13:17AM +0100, Torstein Hegge wrote:
If we can find some other explanation for the 'cannot get freq' and the
large negative rate you saw earlier, it might help to replace the
if (cur_rate != prev_rate) {
with
if (rate != prev_rate) {
so that we do the reset if the target rate is different from the
previous rate, ignoring what the device thinks its current rate is.
I had another look at the logs. If we choose to selectively ignore the
'cannot get freq', the other problems occurred directly after a missing
reset due to the device not reporting the just set rate when reading
back the rate. I think this is worth trying.
diff --git a/sound/usb/clock.c b/sound/usb/clock.c
index 746ec9b..68e1ac3 100644
--- a/sound/usb/clock.c
+++ b/sound/usb/clock.c
@@ -311,7 +311,7 @@ static int set_sample_rate_v2(struct snd_usb_audio *chip,
int iface,
/* Some devices doesn't respond to sample rate changes while the
* interface is active. */
- if (cur_rate != prev_rate) {
+ if (rate != prev_rate) {
switch (chip-usb_id) {
/* C-Media CM6610/CM6620/CM6631 */
case USB_ID(0x054c, 0x06cf): /* Sony */
Ok, I've made that change. I've also put a (v2) in some of the
error message strings.
The kernel's compiled and I'm testing. Cutting to the chase, I can't
seem to get it to misbehave any more.
Here's the tail -f /var/log/kern.log with my comments interspersed:
clh@temuko:~$ tail -f /var/log/kern.log
Mar 17 19:17:01 temuko kernel: [ 19.810439] clean.
Mar 17 19:17:06 temuko kernel: [ 24.237448] wlan0: authenticate with
20:76:00:0d:dd:00
Mar 17 19:17:06 temuko kernel: [ 24.241875] wlan0:
capabilities/regulatory prevented using AP HT/VHT configuration,
downgraded
Mar 17 19:17:06 temuko kernel: [ 24.242097] wlan0: send auth to
20:76:00:0d:dd:00 (try 1/3)
Mar 17 19:17:06 temuko kernel: [ 24.243578] wlan0: authenticated
Mar 17 19:17:06 temuko kernel: [ 24.243903] ath5k :02:02.0
wlan0: disabling HT/VHT due to WEP/TKIP use
Mar 17 19:17:06 temuko kernel: [ 24.244045] wlan0: associate with
20:76:00:0d:dd:00 (try 1/3)
Mar 17 19:17:06 temuko kernel: [ 24.246152] wlan0: RX AssocResp from
20:76:00:0d:dd:00 (capab=0x411 status=0 aid=2)
Mar 17 19:17:06 temuko kernel: [ 24.246485] wlan0: associated
Mar 17 19:17:06 temuko kernel: [ 24.246550] IPv6:
ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
(plugging in now)
Mar 17 19:21:31 temuko kernel: [ 290.700080] usb 1-3: new high-speed
USB device number 2 using ehci-pci
Mar 17 19:21:31 temuko kernel: [ 290.857817] usb 1-3: config 1
interface 8 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64
Mar 17 19:21:31 temuko kernel: [ 290.857830] usb 1-3: config 1
interface 8 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64
Mar 17 19:21:31 temuko kernel: [ 290.860286] usb 1-3: New USB device
found, idVendor=0d8c, idProduct=0304
Mar 17 19:21:31 temuko kernel: [ 290.860298] usb 1-3: New USB device
strings: Mfr=1, Product=2, SerialNumber=0
Mar 17 19:21:31 temuko kernel: [ 290.860309] usb 1-3: Product: Schiit
USB Interface
Mar 17 19:21:31 temuko kernel: [ 290.860320] usb 1-3: Manufacturer: CMEDIA
Mar 17 19:21:32 temuko kernel: [ 291.221135] usbcore: registered new
interface driver usbhid
Mar 17 19:21:32 temuko kernel: [ 291.221146] usbhid: USB HID core driver
Mar 17 19:21:32 temuko kernel: [ 291.328752] 2:1: resetting device
after change 48000 - 192000 (v2)
Mar 17 19:21:32 temuko kernel: [ 291.340612] usbcore: registered new
interface driver snd-usb-audio
Mar 17 19:21:32 temuko kernel: [ 291.422005] input: CMEDIA Schiit USB
Interface as /devices/pci:00/:00:13.2/usb1/1-3/1-3:1.6/input/input7
Mar 17 19:21:32 temuko kernel: [ 291.422576] hid-generic
0003:0D8C:0304.0001: input,hidraw0: USB HID v1.00 Device [CMEDIA
Schiit USB Interface] on usb-:00:13.2-3/input6
(ok continuing on with this device:
plughw:CARD=Interface,DEV=0
Schiit USB Interface, USB Audio
Hardware device with all software conversions
)
(aplay on the 44.1/16
)Mar 17 19:23:48 temuko kernel: [ 427.718349] 2:1: resetting device
after change 192000 - 44100 (v2)
(that's working fine, see my (v2) above. interesting it was at 192 before)
(ctrl-c and aplay on the 96/24 file)
Mar 17 19:24:57 temuko kernel: [ 496.946829] 2:1: resetting device
after change 44100 - 96000 (v2)
(also good, ctrl-c and back to the 44.1/16)
Mar 17 19:25:23 temuko kernel: [ 522.368867] 2:1: resetting device
after change 96000 - 44100 (v2)
(also good, ctrl-c and back to the 96/24)
Mar 17 19:25:44 temuko kernel: [ 543.792783] 2:1: resetting device
after change 44100 - 96000 (v2)
(also good, ctrl-c and trying the 44.1/16 then the 96/24 on the same
command line)
Mar 17 19:26:27 temuko kernel: [ 586.737842] 2:1: resetting device
after change 96000 - 44100 (v2)
(that works,
Re: [Alsa-user] Status of CM6631 USB
On Wed, Mar 13, 2013 at 09:00:29PM -0700, chris hermansen wrote:
Looking at the messages, I find it odd that the reset doesn't happen
cf. we just jump to the complaint about the rates not matching.
Mar 13 20:33:51 temuko kernel: [ 372.014273] current rate 96000 is
different from the runtime rate 44100
Looking at the code...
Torstein, I am not completely following all the details here but I see
in the patched clock.c
if (cur_rate != rate) {
snd_printk(KERN_WARNING
current rate %d is different from the
runtime rate %d\n,
cur_rate, rate);
}
/* Some devices doesn't respond to sample rate changes while the
* interface is active. */
if (cur_rate != prev_rate) {
switch (chip-usb_id) {
/* C-Media CM6610/CM6620/CM6631 */
I am not following why you check for cur_rate and rate being unequal
in the first case and cur_rate and prev_rate being unequal in the
second.
Is this intentional, and I'm missing the wonderful subtlety of it all?
The operations done before that bit you quoted is essentially
prev_rate = get_rate();
set_rate(rate);
cur_rate = get_rate();
The first check is a consistency check to ensure that the rate we read
back is the same as the one we just set. In a working set-up, this
shouldn't happen.
We then check for a change in sample rate by comparing the value read
before the set-operation to the value read after the set-operation.
If your device consistently fails the sanity check by returning a wrong
value in the second get_rate(), it might be that the device has some
issues with responding properly to a rate request after a rate set, but
as noted earlier:
After the sample rate is set to 44.1k, it reads back the previous rate
of 96k. The reset is then skipped, as the previous rate and the current
rate is equal, even if the target rate is different. If this was the
only issue, it could be avoided by comparing the previous rate and the
target rate when determining if the reset is necessary. But the
mangled rate read and the 'cannot get freq' in your previous run
suggests that there are other issues.
If we can find some other explanation for the 'cannot get freq' and the
large negative rate you saw earlier, it might help to replace the
if (cur_rate != prev_rate) {
with
if (rate != prev_rate) {
so that we do the reset if the target rate is different from the
previous rate, ignoring what the device thinks its current rate is.
Torstein
--
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_mar
___
Alsa-user mailing list
Alsa-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] Status of CM6631 USB
Torstein and list;
On Tue, Mar 12, 2013 at 1:48 PM, Torstein Hegge he...@resisty.net wrote:
On Tue, Mar 12, 2013 at 07:59:52AM -0700, chris hermansen wrote:
Mar 12 07:13:34 temuko kernel: [ 1221.640038] usb 1-3: new high-speed
USB device number 2 using ehci-pci
Mar 12 07:13:34 temuko kernel: [ 1221.797930] usb 1-3: config 1
interface 8 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64
Mar 12 07:13:34 temuko kernel: [ 1221.797943] usb 1-3: config 1
interface 8 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64
The device still thinks it should care about midi. I don't want to
completely drop the theory about interaction with things not really
supported. Here is another patch on top of the previous quirks-table.h
entry, ignoring the midi interface as well.
diff --git a/sound/usb/quirks-table.h b/sound/usb/quirks-table.h
index f2fcc78..66ade73 100644
--- a/sound/usb/quirks-table.h
+++ b/sound/usb/quirks-table.h
@@ -3270,6 +3270,18 @@ YAMAHA_DEVICE(0x7010, UB99),
.type = QUIRK_IGNORE_INTERFACE
},
{
+ .ifnum = 6,
+ .type = QUIRK_IGNORE_INTERFACE
+ },
+ {
+ .ifnum = 7,
+ .type = QUIRK_IGNORE_INTERFACE
+ },
+ {
+ .ifnum = 8,
+ .type = QUIRK_IGNORE_INTERFACE
+ },
+ {
.ifnum = -1
}
}
This has the side effect of ignoring the USB HID interface as well, but
I don't think that does anything useful anyway.
I added that patch and rebuilt the kernel.
[ last experiment's evidence deleted ]
Here's the tail -f results this time. You can see I hit a similar
snag after switching back and forth a few times between 44.1/16 and
96/24.
clh@temuko:~$ tail -f /var/log/kern.log
Mar 13 20:27:58 temuko kernel: [ 19.781445] IPv6:
ADDRCONF(NETDEV_UP): wlan0: link is not ready
Mar 13 20:28:03 temuko kernel: [ 24.521089] wlan0: authenticate with
20:76:00:0d:dd:00
Mar 13 20:28:03 temuko kernel: [ 24.525107] wlan0:
capabilities/regulatory prevented using AP HT/VHT configuration,
downgraded
Mar 13 20:28:03 temuko kernel: [ 24.525317] wlan0: send auth to
20:76:00:0d:dd:00 (try 1/3)
Mar 13 20:28:03 temuko kernel: [ 24.526923] wlan0: authenticated
Mar 13 20:28:03 temuko kernel: [ 24.527235] ath5k :02:02.0
wlan0: disabling HT/VHT due to WEP/TKIP use
Mar 13 20:28:03 temuko kernel: [ 24.528054] wlan0: associate with
20:76:00:0d:dd:00 (try 1/3)
Mar 13 20:28:03 temuko kernel: [ 24.530347] wlan0: RX AssocResp from
20:76:00:0d:dd:00 (capab=0x411 status=0 aid=1)
Mar 13 20:28:03 temuko kernel: [ 24.530674] wlan0: associated
Mar 13 20:28:03 temuko kernel: [ 24.530692] IPv6:
ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
(plugging in the Schiit now)
Mar 13 20:29:43 temuko kernel: [ 124.304074] usb 1-3: new high-speed
USB device number 2 using ehci-pci
Mar 13 20:29:44 temuko kernel: [ 124.461835] usb 1-3: config 1
interface 8 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64
Mar 13 20:29:44 temuko kernel: [ 124.461848] usb 1-3: config 1
interface 8 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64
Mar 13 20:29:44 temuko kernel: [ 124.464453] usb 1-3: New USB device
found, idVendor=0d8c, idProduct=0304
Mar 13 20:29:44 temuko kernel: [ 124.464466] usb 1-3: New USB device
strings: Mfr=1, Product=2, SerialNumber=0
Mar 13 20:29:44 temuko kernel: [ 124.464477] usb 1-3: Product: Schiit
USB Interface
Mar 13 20:29:44 temuko kernel: [ 124.464487] usb 1-3: Manufacturer: CMEDIA
Mar 13 20:29:44 temuko kernel: [ 124.960360] 2:1: resetting device
after change 48000 - 192000
Mar 13 20:29:44 temuko kernel: [ 124.971954] usbcore: registered new
interface driver usbhid
Mar 13 20:29:44 temuko kernel: [ 124.971963] usbhid: USB HID core driver
Mar 13 20:29:44 temuko kernel: [ 124.977251] usbcore: registered new
interface driver snd-usb-audio
(starting testing on 44.1/16)
Mar 13 20:31:24 temuko kernel: [ 224.728339] 2:1: resetting device
after change 192000 - 44100
(sounds great)
(ctrl-c and on to the 96/24)
Mar 13 20:32:12 temuko kernel: [ 272.768623] 2:1: resetting device
after change 44100 - 96000
(working fine, ctrl-c and back to the 44.1/16)
Mar 13 20:32:45 temuko kernel: [ 305.741080] 2:1: resetting device
after change 96000 - 44100
(working fine, ctrl-c and back to the 96/24)
Mar 13 20:33:06 temuko kernel: [ 326.579310] 2:1: resetting device
after change 44100 - 96000
(working fine. ctrl-c and trying to play both on one aplay line)
Mar 13 20:33:51 temuko kernel: [ 372.014273] current rate 96000 is
different from the runtime rate 44100
(oops got alvin and the chipmunks here on the 44.1/16.
Re: [Alsa-user] Status of CM6631 USB
Torstein and list;
Sorry about the delay with this, life and the garden and what-not kind
of caught up with me over the last few days...
On Sat, Mar 9, 2013 at 12:35 PM, Torstein Hegge he...@resisty.net wrote:
[last experiment's evidence deleted]
According to lsusb -v from
https://gist.github.com/storrgie/2897496
the initialization goes through iface 1-5 which are
2: SPDIF Output
3: Microphone In
4: Line In
5: SPDIF Input
and when it gets to SPDIF Input altsetting 2, uac_clock_source_is_valid()
fails.
Other CM6631-devices doesn't expose iface 2-5. These extra exposed interfaces
only observable difference between the Schiit and other devices.
[more evidence from last experiment deleted]
If the attempts at modifying the rate of the SPDIF output from the
CM6631 interferes with the intended operation, that might explain why
the Schiit Bifrost still has issues with the workaround applied, while
the Corda Daccord and Asus Xonar Essence One works fine.
The theory doesn't fit that well with your previous experience where the
problem first occurred long after plugging in the device, but it should be
easy to test by ignoring the extra interfaces exposed by the Schiit:
diff --git a/sound/usb/quirks-table.h b/sound/usb/quirks-table.h
index 64d25a7..f2fcc78 100644
--- a/sound/usb/quirks-table.h
+++ b/sound/usb/quirks-table.h
@@ -3238,4 +3238,42 @@ YAMAHA_DEVICE(0x7010, UB99),
}
},
+/* Schiit USB Interface */
+{
+ USB_DEVICE(0x0d8c, 0x0304),
+ .driver_info = (unsigned long) (const struct snd_usb_audio_quirk) {
+ .ifnum = QUIRK_ANY_INTERFACE,
+ .type = QUIRK_COMPOSITE,
+ .data = (const struct snd_usb_audio_quirk[]) {
+ {
+ .ifnum = 0,
+ .type = QUIRK_AUDIO_STANDARD_INTERFACE
+ },
+ {
+ .ifnum = 1,
+ .type = QUIRK_AUDIO_STANDARD_INTERFACE
+ },
+ {
+ .ifnum = 2,
+ .type = QUIRK_IGNORE_INTERFACE
+ },
+ {
+ .ifnum = 3,
+ .type = QUIRK_IGNORE_INTERFACE
+ },
+ {
+ .ifnum = 4,
+ .type = QUIRK_IGNORE_INTERFACE
+ },
+ {
+ .ifnum = 5,
+ .type = QUIRK_IGNORE_INTERFACE
+ },
+ {
+ .ifnum = -1
+ }
+ }
+ }
+},
+
#undef USB_DEVICE_VENDOR_SPEC
So here is what I did.
First, I got the latest Ubuntu Raring kernel sources 3.8.0.11
Then I applied the two patches to clock.c (the fix, and the debugging
output). Note that once again I had to hand-patch the debugging
patch. I should probably figure out what's wrong but one problem at a
time
Then I applied the patch above to quirks-table.h
Then I built the kernel, installed it and rebooted.
Then I did a tail -f /var/log/kern.log and started my experiment.
I've annotated the log file as I went by typing stuff into the
terminal and occasionally cutting and pasting.
As you will see below mid-way through I decided to try disabling pulse
audio, and was not able to make the Schiit misbehave after that point.
Prior to that, on the 5th play, I obsreved a problem, again as you
will see below.
This seems pretty inconclusive to me.
clh@temuko:~$ tail -f /var/log/kern.log
Mar 12 06:53:34 temuko kernel: [ 22.296617] IPv6:
ADDRCONF(NETDEV_UP): eth0: link is not ready
Mar 12 06:53:39 temuko kernel: [ 27.261776] wlan0: authenticate with
20:76:00:0d:dd:00
Mar 12 06:53:39 temuko kernel: [ 27.265983] wlan0:
capabilities/regulatory prevented using AP HT/VHT configuration,
downgraded
Mar 12 06:53:39 temuko kernel: [ 27.266199] wlan0: send auth to
20:76:00:0d:dd:00 (try 1/3)
Mar 12 06:53:39 temuko kernel: [ 27.267707] wlan0: authenticated
Mar 12 06:53:39 temuko kernel: [ 27.268070] ath5k :02:02.0
wlan0: disabling HT/VHT due to WEP/TKIP use
Mar 12 06:53:39 temuko kernel: [ 27.272045] wlan0: associate with
20:76:00:0d:dd:00 (try 1/3)
Mar 12 06:53:39 temuko kernel: [ 27.274162] wlan0: RX AssocResp from
20:76:00:0d:dd:00 (capab=0x411 status=0 aid=1)
Mar 12 06:53:39 temuko kernel: [ 27.274497] wlan0: associated
Mar 12 06:53:39 temuko kernel: [ 27.274561] IPv6:
ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
(plugging in the Schiit usb)
Mar 12 07:13:34 temuko kernel: [ 1221.640038] usb 1-3: new high-speed
USB device number 2 using ehci-pci
Mar 12 07:13:34 temuko kernel: [ 1221.797930] usb 1-3: config 1
interface 8 altsetting 0 bulk
Re: [Alsa-user] Status of CM6631 USB
On Fri, Mar 08, 2013 at 08:23:54AM -0800, chris hermansen wrote: As to the outcome, I have two. The first is that the problem seems worse now - I get more songs going into staticky noisy mode. The second is the attached excerpt of the kernel log file. Mar 8 08:04:39 temuko kernel: [ 2345.656040] usb 1-3: new high-speed USB device number 2 using ehci-pci Mar 8 08:04:39 temuko kernel: [ 2345.813673] usb 1-3: config 1 interface 8 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64 Mar 8 08:04:39 temuko kernel: [ 2345.813685] usb 1-3: config 1 interface 8 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64 Mar 8 08:04:39 temuko kernel: [ 2345.816049] usb 1-3: New USB device found, idVendor=0d8c, idProduct=0304 Mar 8 08:04:39 temuko kernel: [ 2345.816065] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Mar 8 08:04:39 temuko kernel: [ 2345.816075] usb 1-3: Product: Schiit USB Interface Mar 8 08:04:39 temuko kernel: [ 2345.816084] usb 1-3: Manufacturer: CMEDIA Mar 8 08:04:40 temuko kernel: [ 2346.347558] usbcore: registered new interface driver usbhid Mar 8 08:04:40 temuko kernel: [ 2346.347575] usbhid: USB HID core driver Everything looks good up to this point. Mar 8 08:04:40 temuko kernel: [ 2346.419355] 2:1:2: cannot set freq 192000 (v2) Mar 8 08:04:40 temuko kernel: [ 2346.423501] 2:2:1: cannot set freq 192000 (v2) Mar 8 08:04:40 temuko kernel: [ 2346.427353] 2:2:2: cannot get freq (v2) Mar 8 08:04:40 temuko kernel: [ 2346.429728] parse_audio_format_rates_v2(): unable to retrieve sample rate range (clock 16) Mar 8 08:04:40 temuko kernel: [ 2346.452987] 2:5:1: clock source 19 is not valid, cannot use Mar 8 08:04:40 temuko kernel: [ 2346.456614] 2:5:2: cannot set freq 192000 (v2) Mar 8 08:04:40 temuko kernel: [ 2346.457200] cannot get ctl value: req = 0x83, wValue = 0x201, wIndex = 0x0, type = 4 But this looks quite bad. Did this happen when you were testing v2? Your system probably still has the old kern.log files. Mar 8 08:04:40 temuko kernel: [ 2346.462389] usbcore: registered new interface driver snd-usb-audio Mar 8 08:04:40 temuko kernel: [ 2346.476819] input: CMEDIA Schiit USB Interface as /devices/pci:00/:00:13.2/usb1/1-3/1-3:1.6/input/input7 Mar 8 08:04:40 temuko kernel: [ 2346.477523] hid-generic 0003:0D8C:0304.0001: input,hidraw0: USB HID v1.00 Device [CMEDIA Schiit USB Interface] on usb-:00:13.2-3/input6 I'm fairly certain something got mixed up when you were applying the patches. If you don't get messages like 3:1: resetting device after change 48000 - 192000 your device never gets reset after sample rate changes, so the behaviour should be just as bad as without the patches. Torstein -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] Status of CM6631 USB
Torstein and list; On Sat, Mar 9, 2013 at 12:00 AM, Torstein Hegge he...@resisty.net wrote: On Fri, Mar 08, 2013 at 08:23:54AM -0800, chris hermansen wrote: As to the outcome, I have two. (blush) (blush) (blush) What an idiot I am! A new kernel snuck into the updates while I wasn't paying attention and so I was testing that which I did not build. (blush) (blush) (blush) Anyway, I booted up the kernel I wished to test and now I get Torstein's messages. So, it seems this Saturday morning was the perfect morning to test things out. I plugged in the Schiit, then with 'sudo aplay -vD plughw:CARD=Interface,DEV=0' I played: 1. a 44.1/16 for ~ 10 seconds - it sounded fine - so I interrupted it 2. a 96/24 - it was staticky / noisy, even though the plughw slave reported it at 96000 - I interrupted it 3. the same 96/24 again - it was fine Here is the stream from /var/log/kern.log, as it all occurred clh@temuko:~/kernel$ tail -f /var/log/kern.log Mar 9 08:29:14 temuko kernel: [ 20.739688] type=1400 audit(1362846554.667:11): apparmor=STATUS operation=profile_load name=/usr/lib/lightdm/lightdm/lightdm-guest-session-wrapper//chromium_browser pid=872 comm=apparmor_parser Mar 9 08:29:18 temuko kernel: [ 24.377410] wlan0: authenticate with 20:76:00:0d:dd:00 Mar 9 08:29:18 temuko kernel: [ 24.381740] wlan0: capabilities/regulatory prevented using AP HT/VHT configuration, downgraded Mar 9 08:29:18 temuko kernel: [ 24.381963] wlan0: send auth to 20:76:00:0d:dd:00 (try 1/3) Mar 9 08:29:18 temuko kernel: [ 24.383464] wlan0: authenticated Mar 9 08:29:18 temuko kernel: [ 24.383792] ath5k :02:02.0 wlan0: disabling HT/VHT due to WEP/TKIP use Mar 9 08:29:18 temuko kernel: [ 24.384050] wlan0: associate with 20:76:00:0d:dd:00 (try 1/3) Mar 9 08:29:18 temuko kernel: [ 24.386214] wlan0: RX AssocResp from 20:76:00:0d:dd:00 (capab=0x411 status=0 aid=1) Mar 9 08:29:18 temuko kernel: [ 24.386545] wlan0: associated Mar 9 08:29:18 temuko kernel: [ 24.386606] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready Mar 9 08:33:05 temuko kernel: [ 250.380056] usb 1-3: new high-speed USB device number 2 using ehci-pci Mar 9 08:33:05 temuko kernel: [ 250.537896] usb 1-3: config 1 interface 8 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64 Mar 9 08:33:05 temuko kernel: [ 250.537909] usb 1-3: config 1 interface 8 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64 Mar 9 08:33:05 temuko kernel: [ 250.540454] usb 1-3: New USB device found, idVendor=0d8c, idProduct=0304 Mar 9 08:33:05 temuko kernel: [ 250.540480] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Mar 9 08:33:05 temuko kernel: [ 250.540490] usb 1-3: Product: Schiit USB Interface Mar 9 08:33:05 temuko kernel: [ 250.540499] usb 1-3: Manufacturer: CMEDIA Mar 9 08:33:05 temuko kernel: [ 250.910794] 2:1: resetting device after change 48000 - 192000 Mar 9 08:33:05 temuko kernel: [ 250.926921] 2:2: resetting device after change 48000 - 192000 Mar 9 08:33:05 temuko kernel: [ 250.954813] 2:3: resetting device after change 48000 - 192000 Mar 9 08:33:05 temuko kernel: [ 250.966681] 2:4: resetting device after change 48000 - 192000 Mar 9 08:33:05 temuko kernel: [ 250.979809] current rate 48000 is different from the runtime rate 192000 Mar 9 08:33:05 temuko kernel: [ 250.979822] 2:5: resetting device after change -595519488 - 48000 Mar 9 08:33:05 temuko kernel: [ 250.984816] 2:5:2: clock source 19 is not valid, cannot use Mar 9 08:33:05 temuko kernel: [ 250.985339] cannot get ctl value: req = 0x83, wValue = 0x201, wIndex = 0x0, type = 4 Mar 9 08:33:05 temuko kernel: [ 250.995007] usbcore: registered new interface driver usbhid Mar 9 08:33:05 temuko kernel: [ 250.995022] usbhid: USB HID core driver Mar 9 08:33:05 temuko kernel: [ 251.012102] usbcore: registered new interface driver snd-usb-audio Mar 9 08:33:05 temuko kernel: [ 251.139444] input: CMEDIA Schiit USB Interface as /devices/pci:00/:00:13.2/usb1/1-3/1-3:1.6/input/input7 Mar 9 08:33:05 temuko kernel: [ 251.140092] hid-generic 0003:0D8C:0304.0001: input,hidraw0: USB HID v1.00 Device [CMEDIA Schiit USB Interface] on usb-:00:13.2-3/input6 Mar 9 08:33:05 temuko kernel: [ 251.252844] 2:4: resetting device after change 192000 - 44100 Mar 9 08:33:05 temuko kernel: [ 251.276084] 2:1: resetting device after change 192000 - 44100 Mar 9 08:34:55 temuko kernel: [ 361.220050] current rate 44100 is different from the runtime rate 96000 Mar 9 08:34:55 temuko kernel: [ 361.220066] 2:1: resetting device after change -467349503 - 44100 Mar 9 08:35:18 temuko kernel: [ 384.140889] 2:1: resetting device after change 44100 - 96000 ^C clh@temuko:~/kernel$ So that resetting device after change -467349503 - 44100 seems a bit odd. I've tried a few more times and this time annotated the output (like this) of the tail -f session as it happened: clh@temuko:~/kernel$ tail -f /var/log/kern.log Mar 9 08:33:05 temuko kernel: [
Re: [Alsa-user] Status of CM6631 USB
On Sat, Mar 09, 2013 at 09:01:48AM -0800, chris hermansen wrote: I plugged in the Schiit, then with 'sudo aplay -vD plughw:CARD=Interface,DEV=0' I played: 1. a 44.1/16 for ~ 10 seconds - it sounded fine - so I interrupted it 2. a 96/24 - it was staticky / noisy, even though the plughw slave reported it at 96000 - I interrupted it 3. the same 96/24 again - it was fine Here is the stream from /var/log/kern.log, as it all occurred clh@temuko:~/kernel$ tail -f /var/log/kern.log Mar 9 08:33:05 temuko kernel: [ 250.380056] usb 1-3: new high-speed USB device number 2 using ehci-pci Mar 9 08:33:05 temuko kernel: [ 250.537896] usb 1-3: config 1 interface 8 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64 Mar 9 08:33:05 temuko kernel: [ 250.537909] usb 1-3: config 1 interface 8 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64 Mar 9 08:33:05 temuko kernel: [ 250.540454] usb 1-3: New USB device found, idVendor=0d8c, idProduct=0304 Mar 9 08:33:05 temuko kernel: [ 250.540480] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Mar 9 08:33:05 temuko kernel: [ 250.540490] usb 1-3: Product: Schiit USB Interface Mar 9 08:33:05 temuko kernel: [ 250.540499] usb 1-3: Manufacturer: CMEDIA Mar 9 08:33:05 temuko kernel: [ 250.910794] 2:1: resetting device after change 48000 - 192000 Mar 9 08:33:05 temuko kernel: [ 250.926921] 2:2: resetting device after change 48000 - 192000 Mar 9 08:33:05 temuko kernel: [ 250.954813] 2:3: resetting device after change 48000 - 192000 Mar 9 08:33:05 temuko kernel: [ 250.966681] 2:4: resetting device after change 48000 - 192000 Mar 9 08:33:05 temuko kernel: [ 250.979809] current rate 48000 is different from the runtime rate 192000 Mar 9 08:33:05 temuko kernel: [ 250.979822] 2:5: resetting device after change -595519488 - 48000 Mar 9 08:33:05 temuko kernel: [ 250.984816] 2:5:2: clock source 19 is not valid, cannot use Mar 9 08:33:05 temuko kernel: [ 250.985339] cannot get ctl value: req = 0x83, wValue = 0x201, wIndex = 0x0, type = 4 According to lsusb -v from https://gist.github.com/storrgie/2897496 the initialization goes through iface 1-5 which are 2: SPDIF Output 3: Microphone In 4: Line In 5: SPDIF Input and when it gets to SPDIF Input altsetting 2, uac_clock_source_is_valid() fails. Other CM6631-devices doesn't expose iface 2-5. These extra exposed interfaces only observable difference between the Schiit and other devices. Mar 9 08:33:05 temuko kernel: [ 250.995007] usbcore: registered new interface driver usbhid Mar 9 08:33:05 temuko kernel: [ 250.995022] usbhid: USB HID core driver Mar 9 08:33:05 temuko kernel: [ 251.012102] usbcore: registered new interface driver snd-usb-audio Mar 9 08:33:05 temuko kernel: [ 251.139444] input: CMEDIA Schiit USB Interface as /devices/pci:00/:00:13.2/usb1/1-3/1-3:1.6/input/input7 Mar 9 08:33:05 temuko kernel: [ 251.140092] hid-generic 0003:0D8C:0304.0001: input,hidraw0: USB HID v1.00 Device [CMEDIA Schiit USB Interface] on usb-:00:13.2-3/input6 Mar 9 08:33:05 temuko kernel: [ 251.252844] 2:4: resetting device after change 192000 - 44100 Mar 9 08:33:05 temuko kernel: [ 251.276084] 2:1: resetting device after change 192000 - 44100 Here the rate is set for 4 (Line In), as well as the expected 1. Mar 9 08:34:55 temuko kernel: [ 361.220050] current rate 44100 is different from the runtime rate 96000 Mar 9 08:34:55 temuko kernel: [ 361.220066] 2:1: resetting device after change -467349503 - 44100 Mar 9 08:35:18 temuko kernel: [ 384.140889] 2:1: resetting device after change 44100 - 96000 The first read of rate is garbled. After setting the rate to 44.1k, the rate is read back as 96k. (playing 96/24) (sounds fine - interrupting 96/24) (playing 44.1/16) Mar 9 08:49:35 temuko kernel: [ 1241.305358] 2:1: resetting device after change 96000 - 44100 (sounds fine - interrupting 44.1/16) (playing 96/24) Mar 9 08:50:32 temuko kernel: [ 1297.804486] 2:1:2: cannot get freq (v2) (ok that is weird, it did not play, and the following came out of the aplay:) The read with snd_usb_ctl_msg() fails, and aborts the rate setting. Playing WAVE '2L50SACD_tr1_96k_stereo.wav' : Signed 24 bit Little Endian in 3bytes, Rate 96000 Hz, Stereo aplay: set_params:1145: Unable to install hw params: [...] (trying the 96/24 again) Mar 9 08:52:13 temuko kernel: [ 1399.137610] 2:1: resetting device after change 44100 - 96000 If the attempts at modifying the rate of the SPDIF output from the CM6631 interferes with the intended operation, that might explain why the Schiit Bifrost still has issues with the workaround applied, while the Corda Daccord and Asus Xonar Essence One works fine. The theory doesn't fit that well with your previous experience where the problem first occurred long after plugging in the device, but it should be easy to test by ignoring the extra
Re: [Alsa-user] Status of CM6631 USB
Hello Torstein and list;
On Thu, Mar 7, 2013 at 12:30 PM, Torstein Hegge he...@resisty.net wrote:
On Wed, Mar 06, 2013 at 01:15:06PM -0800, chris hermansen wrote:
Does this help?
Kind of, but it doesn't bring me much closer to understanding why this
happens.
It would be nice if I could reproduce this.
This might not be relevant at all, but could you try to do this change on top
of v3 of the patch, reproduce the the bug and look at /var/log/kern.log?
Ok, so see below for the results.
diff --git a/sound/usb/clock.c b/sound/usb/clock.c
index 98c4e26..746ec9b 100644
--- a/sound/usb/clock.c
+++ b/sound/usb/clock.c
@@ -304,7 +304,7 @@ static int set_sample_rate_v2(struct snd_usb_audio *chip,
int iface,
cur_rate = data[0] | (data[1] 8) | (data[2] 16) | (data[3]
24);
if (cur_rate != rate) {
- snd_printd(KERN_WARNING
+ snd_printk(KERN_WARNING
current rate %d is different from the runtime
rate %d\n,
cur_rate, rate);
}
@@ -330,8 +330,21 @@ static int set_sample_rate_v2(struct snd_usb_audio
*chip, int iface,
case USB_ID(0x0d8c, 0x0315): /* CM6632A */
case USB_ID(0x0d8c, 0x0319): /* CM6631A */
case USB_ID(0x200c, 0x1030): /* Reloop */
- usb_set_interface(dev, iface, 0);
- usb_set_interface(dev, iface, fmt-altsetting);
+ snd_printk(KERN_WARNING
+ %d:%d: resetting device after change %d
- %d\n,
+ dev-devnum, iface, prev_rate, cur_rate);
+ err = usb_set_interface(dev, iface, 0);
+ if (err 0) {
+ snd_printk(KERN_WARNING
+ %d:%d:%d: cannot reset interface
(%d)\n,
+ dev-devnum, iface, 0, err);
+ }
+ err = usb_set_interface(dev, iface, fmt-altsetting);
+ if (err 0) {
+ snd_printk(KERN_WARNING
+ %d:%d:%d: cannot set interface
(%d)\n,
+ dev-devnum, iface,
fmt-altsetting, err);
+ }
break;
}
}
Going sideways here for a minute - I'm using apt to get the Ubuntu
kernel source for 3.8.0 as opposed to git, so I'm trying to match your
process with patch.
The v3 patch works fine but applying the above doesn't; I get errors
clh@temuko:~/test$ patch clock.c ../patch.th.debug
patching file clock.c
Hunk #1 FAILED at 304.
Hunk #2 FAILED at 330.
2 out of 2 hunks FAILED -- saving rejects to file clock.c.rej
clh@temuko:~/test$
So I manipulated the file by hand.
The build all seemed to go fine.
There are multiple possible outcomes:
1) It fixes the issue. In that case the problem must be very timing
sensitive.
2) The first printk hits. Then the device lies about the current rate.
3) The second printk does not hit. Then the device the device lies about the
previous rate.
4) The reset operation fails. Unlikely, but I should probably have checked the
reported error code anyway.
5) No change. usb_set_interface() after setting sample rate is not always
enough, the device needs to be kicked even harder.
My guess is 5.
As to the outcome, I have two.
The first is that the problem seems worse now - I get more songs going
into staticky noisy mode.
The second is the attached excerpt of the kernel log file.
Please let me know if you'd like to try something else.
--
Chris Hermansen · clhermansen at gmail dot com
C'est ma façon de parler.
kern.log.test
Description: Binary data
--
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev___
Alsa-user mailing list
Alsa-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] Status of CM6631 USB
On Fri, Mar 08, 2013 at 08:23:54AM -0800, chris hermansen wrote: As to the outcome, I have two. The first is that the problem seems worse now - I get more songs going into staticky noisy mode. The second is the attached excerpt of the kernel log file. That looks like the log from plugging in the device, do you get anything written to the log when you play something and switch sample rate? Torstein -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] Status of CM6631 USB
Torstein and list; On Fri, Mar 8, 2013 at 8:43 AM, Torstein Hegge he...@resisty.net wrote: On Fri, Mar 08, 2013 at 08:23:54AM -0800, chris hermansen wrote: As to the outcome, I have two. The first is that the problem seems worse now - I get more songs going into staticky noisy mode. The second is the attached excerpt of the kernel log file. That looks like the log from plugging in the device, do you get anything written to the log when you play something and switch sample rate? Sorry but that is all I get! Let me experiment some more today and send you some more info. By the way since this machine is only for testing, I don't mind doing a remote session with it if you want to test directly. -- Chris Hermansen · clhermansen at gmail dot com C'est ma façon de parler. -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] Status of CM6631 USB
On Wed, Mar 06, 2013 at 01:15:06PM -0800, chris hermansen wrote:
Does this help?
Kind of, but it doesn't bring me much closer to understanding why this happens.
It would be nice if I could reproduce this.
This might not be relevant at all, but could you try to do this change on top
of v3 of the patch, reproduce the the bug and look at /var/log/kern.log?
diff --git a/sound/usb/clock.c b/sound/usb/clock.c
index 98c4e26..746ec9b 100644
--- a/sound/usb/clock.c
+++ b/sound/usb/clock.c
@@ -304,7 +304,7 @@ static int set_sample_rate_v2(struct snd_usb_audio *chip,
int iface,
cur_rate = data[0] | (data[1] 8) | (data[2] 16) | (data[3] 24);
if (cur_rate != rate) {
- snd_printd(KERN_WARNING
+ snd_printk(KERN_WARNING
current rate %d is different from the runtime rate
%d\n,
cur_rate, rate);
}
@@ -330,8 +330,21 @@ static int set_sample_rate_v2(struct snd_usb_audio *chip,
int iface,
case USB_ID(0x0d8c, 0x0315): /* CM6632A */
case USB_ID(0x0d8c, 0x0319): /* CM6631A */
case USB_ID(0x200c, 0x1030): /* Reloop */
- usb_set_interface(dev, iface, 0);
- usb_set_interface(dev, iface, fmt-altsetting);
+ snd_printk(KERN_WARNING
+ %d:%d: resetting device after change %d -
%d\n,
+ dev-devnum, iface, prev_rate, cur_rate);
+ err = usb_set_interface(dev, iface, 0);
+ if (err 0) {
+ snd_printk(KERN_WARNING
+ %d:%d:%d: cannot reset interface
(%d)\n,
+ dev-devnum, iface, 0, err);
+ }
+ err = usb_set_interface(dev, iface, fmt-altsetting);
+ if (err 0) {
+ snd_printk(KERN_WARNING
+ %d:%d:%d: cannot set interface
(%d)\n,
+ dev-devnum, iface, fmt-altsetting,
err);
+ }
break;
}
}
There are multiple possible outcomes:
1) It fixes the issue. In that case the problem must be very timing
sensitive.
2) The first printk hits. Then the device lies about the current rate.
3) The second printk does not hit. Then the device the device lies about the
previous rate.
4) The reset operation fails. Unlikely, but I should probably have checked the
reported error code anyway.
5) No change. usb_set_interface() after setting sample rate is not always
enough, the device needs to be kicked even harder.
My guess is 5.
You should be able to get your kernel tree into that state by saving
http://article.gmane.org/gmane.linux.alsa.devel/106041 as
cm6631-workaround-v3.patch and doing something like
git stash
git checkout -b cm6631-v3-logging origin/master
git am -k cm6631-workaround-v3.patch
git apply patch above
git commit -a -m Add logging
Torstein
--
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
___
Alsa-user mailing list
Alsa-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] Status of CM6631 USB
Torstein, list: On Tue, Mar 5, 2013 at 11:18 PM, Torstein Hegge he...@resisty.net wrote: On Tue, Mar 05, 2013 at 03:44:04PM -0800, chris hermansen wrote: On Tue, Mar 5, 2013 at 3:03 PM, chris hermansen clherman...@gmail.com wrote: On Mon, Mar 4, 2013 at 6:44 PM, chris hermansen clherman...@gmail.com wrote: On Mon, Mar 4, 2013 at 2:44 PM, Torstein Hegge he...@resisty.net wrote: On Mon, Mar 04, 2013 at 11:30:03AM -0800, chris hermansen wrote: I would be happy to test this on my Schiit Bifrost as well. I'm currently using the TOSLINK connection but it would be easy peasy to hook up a laptop via the USB. If you could test the patch i just posted to alsa-devel [1], that would be great. [1] http://article.gmane.org/gmane.linux.alsa.devel/106002 I will do my best to test it tonight (GMT-8). Well, last night came and went and time was short. Anyway, this morning I booted up my old Toshiba testbed currently running Lubuntu 13.04 and followed these instructions to build a new kernel: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel (by the way if anyone is reading this and thinking I want to try too, establish the build environment BEFORE trying to get the kernel source). 13.04 is running 3.8.0 kernel at this point in time. I inserted Torstein's code into line 713 in pcm.c and built the kernel. I tried sudo aplay -vD plughw:CARD=Interface,DEV=0 with my 44.1/16 wav file followed by my 96/24 wav file and... IT WORKS Great, thanks for testing. My pleasure! I know this isn't quite testing the patch itself, but I wasn't comfortable with the different versions. Should I do more? You might find it easier to keep track of the changes by saving the full patch email to a file and applying it with $ git am filename Then you'll get the commit message in your log as well. Thanks for the pointer. Answering my own question, I decided to take a closer look at your patch noted above (106002), which appears to patch sound/usb/clock.c, which seems completely different than what you presented earlier, which was the change to sound/usb/pcm.c, which is what I tested... Feeling a bit lost here... did I miss a part of the conversation? You might have missed the discussion of the first patch, http://thread.gmane.org/gmane.linux.alsa.devel/105941/focus=105971 Yes probably. Perhaps it's the dev as opposed to user list? The important bit is the same between v1 and v2, usb_set_interface() after setting sample frequency. v2 just tries to be a bit smarter, by just doing the reset on sample rate changes. So I have now tried the v2 patch. It seems to work mostly. I can't create a problem with aplay using a device of plughw:CARD=Interface,DEV=0 switching between 44.1/16 and 96/24 tracks. Using gmusicbrowser with alsa and a device of plughw:CARD=Interface,DEV=0 once in awhile I seem to move to a 96/24 that plays in the old bad noisy/static-y fashion, but I can't seem to re-create the circumstances reliably. If it happens, it seems to be when I use the fast forward to skip to the next song. It has not happened more than once in a given gmusicbrowser session, of which I have probably tried 10 now, and it has only happened three times. I don't know what the problem might be. It could be some weird thing in gmusicbrowser, too. To add to the confusion, I sent v3 of the patch as well. This is a minor change over v2, but adds support for more cards based on C-Media chips, like Asus Xonar Essence One. I haven't tried that one. Please let me know if you would like me to try some more experimenting. And thanks again for trying to fix this! -- Chris Hermansen · clhermansen at gmail dot com C'est ma façon de parler. -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] Status of CM6631 USB
Torsten and list; On Mon, Mar 4, 2013 at 6:44 PM, chris hermansen clherman...@gmail.comwrote: Torstein and list; On Mon, Mar 4, 2013 at 2:44 PM, Torstein Hegge he...@resisty.net wrote: On Mon, Mar 04, 2013 at 11:30:03AM -0800, chris hermansen wrote: I would be happy to test this on my Schiit Bifrost as well. I'm currently using the TOSLINK connection but it would be easy peasy to hook up a laptop via the USB. If you could test the patch i just posted to alsa-devel [1], that would be great. [1] http://article.gmane.org/gmane.linux.alsa.devel/106002 I will do my best to test it tonight (GMT-8). Well, last night came and went and time was short. Anyway, this morning I booted up my old Toshiba testbed currently running Lubuntu 13.04 and followed these instructions to build a new kernel: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel (by the way if anyone is reading this and thinking I want to try too, establish the build environment BEFORE trying to get the kernel source). 13.04 is running 3.8.0 kernel at this point in time. I inserted Torstein's code into line 713 in pcm.c and built the kernel. I tried sudo aplay -vD plughw:CARD=Interface,DEV=0 with my 44.1/16 wav file followed by my 96/24 wav file and... IT WORKS Congratulations, Torstein. I know this isn't quite testing the patch itself, but I wasn't comfortable with the different versions. Should I do more? -- Chris Hermansen · clhermansen at gmail dot com C'est ma façon de parler. -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] Status of CM6631 USB
Torstein and list; On Tue, Mar 5, 2013 at 3:03 PM, chris hermansen clherman...@gmail.com wrote: Torsten and list; On Mon, Mar 4, 2013 at 6:44 PM, chris hermansen clherman...@gmail.com wrote: Torstein and list; On Mon, Mar 4, 2013 at 2:44 PM, Torstein Hegge he...@resisty.net wrote: On Mon, Mar 04, 2013 at 11:30:03AM -0800, chris hermansen wrote: I would be happy to test this on my Schiit Bifrost as well. I'm currently using the TOSLINK connection but it would be easy peasy to hook up a laptop via the USB. If you could test the patch i just posted to alsa-devel [1], that would be great. [1] http://article.gmane.org/gmane.linux.alsa.devel/106002 I will do my best to test it tonight (GMT-8). Well, last night came and went and time was short. Anyway, this morning I booted up my old Toshiba testbed currently running Lubuntu 13.04 and followed these instructions to build a new kernel: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel (by the way if anyone is reading this and thinking I want to try too, establish the build environment BEFORE trying to get the kernel source). 13.04 is running 3.8.0 kernel at this point in time. I inserted Torstein's code into line 713 in pcm.c and built the kernel. I tried sudo aplay -vD plughw:CARD=Interface,DEV=0 with my 44.1/16 wav file followed by my 96/24 wav file and... IT WORKS Congratulations, Torstein. I know this isn't quite testing the patch itself, but I wasn't comfortable with the different versions. Should I do more? Answering my own question, I decided to take a closer look at your patch noted above (106002), which appears to patch sound/usb/clock.c, which seems completely different than what you presented earlier, which was the change to sound/usb/pcm.c, which is what I tested... Feeling a bit lost here... did I miss a part of the conversation? -- Chris Hermansen · clhermansen at gmail dot com C'est ma façon de parler. -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] Status of CM6631 USB
On Tue, Mar 05, 2013 at 03:44:04PM -0800, chris hermansen wrote: On Tue, Mar 5, 2013 at 3:03 PM, chris hermansen clherman...@gmail.com wrote: On Mon, Mar 4, 2013 at 6:44 PM, chris hermansen clherman...@gmail.com wrote: On Mon, Mar 4, 2013 at 2:44 PM, Torstein Hegge he...@resisty.net wrote: On Mon, Mar 04, 2013 at 11:30:03AM -0800, chris hermansen wrote: I would be happy to test this on my Schiit Bifrost as well. I'm currently using the TOSLINK connection but it would be easy peasy to hook up a laptop via the USB. If you could test the patch i just posted to alsa-devel [1], that would be great. [1] http://article.gmane.org/gmane.linux.alsa.devel/106002 I will do my best to test it tonight (GMT-8). Well, last night came and went and time was short. Anyway, this morning I booted up my old Toshiba testbed currently running Lubuntu 13.04 and followed these instructions to build a new kernel: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel (by the way if anyone is reading this and thinking I want to try too, establish the build environment BEFORE trying to get the kernel source). 13.04 is running 3.8.0 kernel at this point in time. I inserted Torstein's code into line 713 in pcm.c and built the kernel. I tried sudo aplay -vD plughw:CARD=Interface,DEV=0 with my 44.1/16 wav file followed by my 96/24 wav file and... IT WORKS Great, thanks for testing. I know this isn't quite testing the patch itself, but I wasn't comfortable with the different versions. Should I do more? You might find it easier to keep track of the changes by saving the full patch email to a file and applying it with $ git am filename Then you'll get the commit message in your log as well. Answering my own question, I decided to take a closer look at your patch noted above (106002), which appears to patch sound/usb/clock.c, which seems completely different than what you presented earlier, which was the change to sound/usb/pcm.c, which is what I tested... Feeling a bit lost here... did I miss a part of the conversation? You might have missed the discussion of the first patch, http://thread.gmane.org/gmane.linux.alsa.devel/105941/focus=105971 The important bit is the same between v1 and v2, usb_set_interface() after setting sample frequency. v2 just tries to be a bit smarter, by just doing the reset on sample rate changes. To add to the confusion, I sent v3 of the patch as well. This is a minor change over v2, but adds support for more cards based on C-Media chips, like Asus Xonar Essence One. Torstein -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] Status of CM6631 USB
Gentlemen;
On Sat, Mar 2, 2013 at 4:21 AM, Daniel Mack zon...@gmail.com wrote:
Hi Torstein,
(+ alsa-devel)
On 02.03.2013 12:09, Torstein Hegge wrote:
Daniel Mack zonque at gmail.com writes:
This is a known bug, also most probably flaw in the CMEDIA chip,
and not yet properly worked around in the snd-usb driver. If you
want to investigate, have a look at the feedback format
autodetection code in sound/usb/endpoint.c.
Thanks, I'll have a look.
I believe what's going on here is that the device is confused after
sample rate changes and keeps sending back feedback data for the old
rate on its feedback endpoint. That causes the autodetection algorithm,
which kicks in on every first packet of a stream, to go nuts, which
causes the part of the driver that sends the data assume a very wrong
rate. Some printk() there should give you a hint.
I had a look at this using another C-Media CM6631 based device, the Corda
Daccord (usbid 0x0d8c, 0x0309). As far as I can see, what happens in the
feedback format auto-detection is:
When starting playback of a file with a different sampling frequency
than the
previous file, the reported feedback frequency is in the same range as
the
previously played file, varying within +-1%.
The feedback format detection gives a shift of -1 and reports the
feedback
frequency as ~48kHz when playing a 44.1kHz file after a 96kHz file. Same
thing
happens when playing a 96kHz file after a 44.1kHz file, the device
reports
feedback frequency in the 44.1kHz range, the feedback format detection
gives a
shift of +1 and reports the feedback frequency as ~88kHz.
That's what I suspected.
Bypassing the feedback format detection by hard-coding the frequency
shift to
zero and setting the feedback frequency ep-freqm equal to the nominal
frequency ep-freqn if the feedback frequency is far off from the
expected
value (like 48kHz when expecting 44.1kHz) does not change the distortion.
Similarly, forcing the feedback detection to run multiple times until it
reaches an acceptable value just keeps the feedback detection to
repeatedly
until playback is stopped. This probably means any amount of skipping
packages
early in the stream won't work.
Ok.
It seems like the device stays in the previous frequency until the
interface
is reset. One possible workaround is to call usb_set_interface() again
after
snd_usb_init_sample_rate(), like this:
I see - that also explains why explicitly stopping and restarting the
stream fixes the problem in most cases, right?
diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c
index d82e378..01978a6 100644
--- a/sound/usb/pcm.c
+++ b/sound/usb/pcm.c
@@ -710,6 +710,16 @@ static int snd_usb_pcm_prepare(struct
snd_pcm_substream
*substream)
subs-need_setup_ep = false;
}
+ /* Some devices doesn't respond to sample rate changes while the
+* interface is active. */
+ switch (subs-stream-chip-usb_id) {
+ case USB_ID(0x0d8c, 0x0304): /* C-Media - Schiit USB Interface */
+ case USB_ID(0x0d8c, 0x0309): /* C-Media CM6631 */
+ usb_set_interface(subs-dev, subs-cur_audiofmt-iface,
+ subs-cur_audiofmt-altset_idx);
+ break;
+ }
+
/* some unit conversions in runtime */
subs-data_endpoint-maxframesize =
bytes_to_frames(runtime,
subs-data_endpoint-maxpacksize);
This fixes all problems related to sample rate changes for me. I have
only
tested with the Daccord, but it should work for the Schiit and other
CM6631
based devices as well.
Many thanks for looking into this! Much appreciated.
Could you cook a real patch please and send it to alsa-devel? Have a
look at Documentation/SubmittingPatches if that's your first submission.
I would be happy to test this on my Schiit Bifrost as well. I'm currently
using the TOSLINK connection but it would be easy peasy to hook up a laptop
via the USB.
--
Chris Hermansen · clhermansen at gmail dot com
C'est ma façon de parler.
--
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_feb___
Alsa-user mailing list
Alsa-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] Status of CM6631 USB
On Mon, Mar 04, 2013 at 11:30:03AM -0800, chris hermansen wrote: I would be happy to test this on my Schiit Bifrost as well. I'm currently using the TOSLINK connection but it would be easy peasy to hook up a laptop via the USB. If you could test the patch i just posted to alsa-devel [1], that would be great. [1] http://article.gmane.org/gmane.linux.alsa.devel/106002 Torstein -- 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_feb ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] Status of CM6631 USB
Torstein and list; On Mon, Mar 4, 2013 at 2:44 PM, Torstein Hegge he...@resisty.net wrote: On Mon, Mar 04, 2013 at 11:30:03AM -0800, chris hermansen wrote: I would be happy to test this on my Schiit Bifrost as well. I'm currently using the TOSLINK connection but it would be easy peasy to hook up a laptop via the USB. If you could test the patch i just posted to alsa-devel [1], that would be great. [1] http://article.gmane.org/gmane.linux.alsa.devel/106002 I will do my best to test it tonight (GMT-8). -- Chris Hermansen · clhermansen at gmail dot com C'est ma façon de parler. -- 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_feb___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] Status of CM6631 USB
Daniel Mack zonque at gmail.com writes:
This is a known bug, also most probably flaw in the CMEDIA chip,
and not yet properly worked around in the snd-usb driver. If you
want to investigate, have a look at the feedback format
autodetection code in sound/usb/endpoint.c.
Thanks, I'll have a look.
I believe what's going on here is that the device is confused after
sample rate changes and keeps sending back feedback data for the old
rate on its feedback endpoint. That causes the autodetection algorithm,
which kicks in on every first packet of a stream, to go nuts, which
causes the part of the driver that sends the data assume a very wrong
rate. Some printk() there should give you a hint.
I had a look at this using another C-Media CM6631 based device, the Corda
Daccord (usbid 0x0d8c, 0x0309). As far as I can see, what happens in the
feedback format auto-detection is:
When starting playback of a file with a different sampling frequency than the
previous file, the reported feedback frequency is in the same range as the
previously played file, varying within +-1%.
The feedback format detection gives a shift of -1 and reports the feedback
frequency as ~48kHz when playing a 44.1kHz file after a 96kHz file. Same thing
happens when playing a 96kHz file after a 44.1kHz file, the device reports
feedback frequency in the 44.1kHz range, the feedback format detection gives a
shift of +1 and reports the feedback frequency as ~88kHz.
Bypassing the feedback format detection by hard-coding the frequency shift to
zero and setting the feedback frequency ep-freqm equal to the nominal
frequency ep-freqn if the feedback frequency is far off from the expected
value (like 48kHz when expecting 44.1kHz) does not change the distortion.
Similarly, forcing the feedback detection to run multiple times until it
reaches an acceptable value just keeps the feedback detection to repeatedly
until playback is stopped. This probably means any amount of skipping packages
early in the stream won't work.
It seems like the device stays in the previous frequency until the interface
is reset. One possible workaround is to call usb_set_interface() again after
snd_usb_init_sample_rate(), like this:
diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c
index d82e378..01978a6 100644
--- a/sound/usb/pcm.c
+++ b/sound/usb/pcm.c
@@ -710,6 +710,16 @@ static int snd_usb_pcm_prepare(struct snd_pcm_substream
*substream)
subs-need_setup_ep = false;
}
+ /* Some devices doesn't respond to sample rate changes while the
+* interface is active. */
+ switch (subs-stream-chip-usb_id) {
+ case USB_ID(0x0d8c, 0x0304): /* C-Media - Schiit USB Interface */
+ case USB_ID(0x0d8c, 0x0309): /* C-Media CM6631 */
+ usb_set_interface(subs-dev, subs-cur_audiofmt-iface,
+ subs-cur_audiofmt-altset_idx);
+ break;
+ }
+
/* some unit conversions in runtime */
subs-data_endpoint-maxframesize =
bytes_to_frames(runtime, subs-data_endpoint-maxpacksize);
This fixes all problems related to sample rate changes for me. I have only
tested with the Daccord, but it should work for the Schiit and other CM6631
based devices as well.
I was initially thinking this could be done in snd_usb_endpoint_start_quirk(),
but the call to usb_set_interface() must be performed before start_endpoints().
Torstein
--
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_feb
___
Alsa-user mailing list
Alsa-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] Status of CM6631 USB
* each time playback format changes (16/44 to 24/96 and back) the sound is totally scrambled, but /proc/asound/card2/pcm0p/sub0/hw_params shows the correct playback format. Stop/start playback solves the problem. This is a known bug, also most probably flaw in the CMEDIA chip, and not yet properly worked around in the snd-usb driver. If you want to investigate, have a look at the feedback format autodetection code in sound/usb/endpoint.c. BTW: in the meantime I've bought a stereo amp which does not have a digital in anymore, so the device was lying around unused for the last three months. If someone else from Germany (shipping costs!) wants to test it, I can lend him the device for three months. -- Thorsten Mühlfelder Salix OS: www.salixos.org -- 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_feb ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] Status of CM6631 USB
I've read a quite long discussion here about this USB Audio 2.0 chip. Apparently there have been problems when switching sample rates. Now I have bought a cheap USB to S/PDIF interface with this chip (search for CM6631 USB at www.aliexpress.com) and I wonder if it is better supported now. Made some photos of the device. If you are interested you can find them in my G+ album: https://plus.google.com/u/0/118078439912946587810/posts/Bgvei3cmECB Greetings Thorsten -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] Status of CM6631 USB
On 12.12.2012 00:42, Thorsten Mühlfelder wrote: The system is running Slackware 14.0 with kernel 3.2.29 (Alsa 1.0.24). This kernel is *way* too old. Please try a 3.7 which has just been released. OK, I've updated to 3.7.0. Now lsusb.py shows the device in high speed: 3-30d8c:0309 ef 2.00 480MBit/s 100mA 3IFs (CMEDIA USB2.0 High-Speed True HD Audio) Also it is possible to play files with 96 kHz sampling rate (S32_LE). Ok, good. Problems left: * There is a blob at the beginning of playback This is most probably a bug in the hardware chain somewhere. Can you exclude the possibilty that this plop is produced by the receiving side and occurs every time the link was lost? You can try that by re-plugging the optical cable while audio is streaming. * each time playback format changes (16/44 to 24/96 and back) the sound is totally scrambled, but /proc/asound/card2/pcm0p/sub0/hw_params shows the correct playback format. Stop/start playback solves the problem. This is a known bug, also most probably flaw in the CMEDIA chip, and not yet properly worked around in the snd-usb driver. If you want to investigate, have a look at the feedback format autodetection code in sound/usb/endpoint.c. Daniel -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] Status of CM6631 USB
Problems left: * There is a blob at the beginning of playback This is most probably a bug in the hardware chain somewhere. Can you exclude the possibilty that this plop is produced by the receiving side and occurs every time the link was lost? You can try that by re-plugging the optical cable while audio is streaming. Replugging the optical cable does not produce any plops or noise. Also the same connection with my PCI sound card works fine. Also I've noticed that the plops aren't always there and vary in volume. Furthermore mpd even produces some noise when pressing stop. This is a known bug, also most probably flaw in the CMEDIA chip, and not yet properly worked around in the snd-usb driver. If you want to investigate, have a look at the feedback format autodetection code in sound/usb/endpoint.c. Thanks, I'll have a look. -- Thorsten Mühlfelder Salix OS: www.salixos.org -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] Status of CM6631 USB
On 12.12.2012 22:20, Thorsten Mühlfelder wrote: Problems left: * There is a blob at the beginning of playback This is most probably a bug in the hardware chain somewhere. Can you exclude the possibilty that this plop is produced by the receiving side and occurs every time the link was lost? You can try that by re-plugging the optical cable while audio is streaming. Replugging the optical cable does not produce any plops or noise. Also the same connection with my PCI sound card works fine. Also I've noticed that the plops aren't always there and vary in volume. Furthermore mpd even produces some noise when pressing stop. Then try with aplay and stream a file that is guaranteed not to have any plopp at the beginning. Might just really be a user space bug then, as I'm not aware of any such issue in the driver. This is a known bug, also most probably flaw in the CMEDIA chip, and not yet properly worked around in the snd-usb driver. If you want to investigate, have a look at the feedback format autodetection code in sound/usb/endpoint.c. Thanks, I'll have a look. I believe what's going on here is that the device is confused after sample rate changes and keeps sending back feedback data for the old rate on its feedback endpoint. That causes the autodetection algorithm, which kicks in on every first packet of a stream, to go nuts, which causes the part of the driver that sends the data assume a very wrong rate. Some printk() there should give you a hint. Daniel -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] Status of CM6631 USB
Yes, the discussion has ended without real solution. So this is why I've asked here again. As soon as the China device arrives I can test if it has the same issues like your Schiit. OK, device has arrived: lsusb: Bus 007 Device 003: ID 0d8c:0309 C-Media Electronics, Inc. lsusb.py: 7-30d8c:0309 ef 2.00 12MBit/s 100mA 3IFs (CMEDIA USB2.0 High-Speed True HD Audio) /var/log/messages: Dec 11 19:48:44 pinkfloyd kernel: [ 853.775100] usb 7-3: new full-speed USB device number 3 using ohci_hcd Dec 11 19:48:44 pinkfloyd kernel: [ 853.915155] usb 7-3: not running at top speed; connect to a high speed hub Dec 11 19:48:44 pinkfloyd kernel: [ 853.934143] usb 7-3: New USB device found, idVendor=0d8c, idProduct=0309 Dec 11 19:48:44 pinkfloyd kernel: [ 853.934154] usb 7-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Dec 11 19:48:44 pinkfloyd kernel: [ 853.934161] usb 7-3: Product: USB2.0 High-Speed True HD Audio Dec 11 19:48:44 pinkfloyd kernel: [ 853.934167] usb 7-3: Manufacturer: CMEDIA Dec 11 19:48:44 pinkfloyd kernel: [ 854.001318] input: CMEDIA USB2.0 High-Speed True HD Audio as /devices/pci:00/:00:16.0/usb7/7-3/7-3:1.2/input/input8 Dec 11 19:48:44 pinkfloyd kernel: [ 854.001694] generic-usb 0003:0D8C:0309.0006: input,hidraw2: USB HID v1.00 Device [CMEDIA USB2.0 High-Speed True HD Audio] on usb-:00:16.0-3/input2 What I've done so far: The device only has digital outputs. I've connected it to my AVR via optical link. For tests I'm using Audacious (output set to hw:2,0; bit depth 32 bit as suggested). The system is running Slackware 14.0 with kernel 3.2.29 (Alsa 1.0.24). Problems: * There is a blob when playback starts * 12MBit/s / full speed USB does not seem valid for me. I've thought USB Audio 2 uses high speed mode? * when trying to play a 24/96 track in Audacious I'm getting ALSA error: snd_pcm_hw_params_set_rate failed: Invalid argument. * using aplay on the same 24/96 file and plughw instead of hw leads to: cat /proc/asound/card2/pcm0p/sub0/hw_params access: MMAP_INTERLEAVED format: S32_LE subformat: STD channels: 2 rate: 48000 (48000/1) period_size: 6000 buffer_size: 24001 Additional questions: * how can I check device capabilities? * which Alsa version is needed for USB Audio 2? -- Thorsten Mühlfelder Salix OS: www.salixos.org -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] Status of CM6631 USB
On 11.12.2012 20:40, Thorsten Mühlfelder wrote: Yes, the discussion has ended without real solution. So this is why I've asked here again. As soon as the China device arrives I can test if it has the same issues like your Schiit. OK, device has arrived: lsusb: Bus 007 Device 003: ID 0d8c:0309 C-Media Electronics, Inc. lsusb.py: 7-30d8c:0309 ef 2.00 12MBit/s 100mA 3IFs (CMEDIA USB2.0 High-Speed True HD Audio) /var/log/messages: Dec 11 19:48:44 pinkfloyd kernel: [ 853.775100] usb 7-3: new full-speed USB device number 3 using ohci_hcd Dec 11 19:48:44 pinkfloyd kernel: [ 853.915155] usb 7-3: not running at top speed; connect to a high speed hub Dec 11 19:48:44 pinkfloyd kernel: [ 853.934143] usb 7-3: New USB device found, idVendor=0d8c, idProduct=0309 Dec 11 19:48:44 pinkfloyd kernel: [ 853.934154] usb 7-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Dec 11 19:48:44 pinkfloyd kernel: [ 853.934161] usb 7-3: Product: USB2.0 High-Speed True HD Audio Dec 11 19:48:44 pinkfloyd kernel: [ 853.934167] usb 7-3: Manufacturer: CMEDIA Dec 11 19:48:44 pinkfloyd kernel: [ 854.001318] input: CMEDIA USB2.0 High-Speed True HD Audio as /devices/pci:00/:00:16.0/usb7/7-3/7-3:1.2/input/input8 Dec 11 19:48:44 pinkfloyd kernel: [ 854.001694] generic-usb 0003:0D8C:0309.0006: input,hidraw2: USB HID v1.00 Device [CMEDIA USB2.0 High-Speed True HD Audio] on usb-:00:16.0-3/input2 What I've done so far: The device only has digital outputs. I've connected it to my AVR via optical link. For tests I'm using Audacious (output set to hw:2,0; bit depth 32 bit as suggested). The system is running Slackware 14.0 with kernel 3.2.29 (Alsa 1.0.24). This kernel is *way* too old. Please try a 3.7 which has just been released. Daniel -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] Status of CM6631 USB
Thorsten, list: On Tue, Dec 11, 2012 at 4:40 PM, Thorsten Mühlfelder thenk...@salixos.org wrote: Yes, the discussion has ended without real solution. So this is why I've asked here again. As soon as the China device arrives I can test if it has the same issues like your Schiit. OK, device has arrived: lsusb: Bus 007 Device 003: ID 0d8c:0309 C-Media Electronics, Inc. lsusb.py: 7-30d8c:0309 ef 2.00 12MBit/s 100mA 3IFs (CMEDIA USB2.0 High-Speed True HD Audio) /var/log/messages: Dec 11 19:48:44 pinkfloyd kernel: [ 853.775100] usb 7-3: new full-speed USB device number 3 using ohci_hcd Dec 11 19:48:44 pinkfloyd kernel: [ 853.915155] usb 7-3: not running at top speed; connect to a high speed hub Dec 11 19:48:44 pinkfloyd kernel: [ 853.934143] usb 7-3: New USB device found, idVendor=0d8c, idProduct=0309 Dec 11 19:48:44 pinkfloyd kernel: [ 853.934154] usb 7-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Dec 11 19:48:44 pinkfloyd kernel: [ 853.934161] usb 7-3: Product: USB2.0 High-Speed True HD Audio Dec 11 19:48:44 pinkfloyd kernel: [ 853.934167] usb 7-3: Manufacturer: CMEDIA Dec 11 19:48:44 pinkfloyd kernel: [ 854.001318] input: CMEDIA USB2.0 High-Speed True HD Audio as /devices/pci:00/:00:16.0/usb7/7-3/7-3:1.2/input/input8 Dec 11 19:48:44 pinkfloyd kernel: [ 854.001694] generic-usb 0003:0D8C:0309.0006: input,hidraw2: USB HID v1.00 Device [CMEDIA USB2.0 High-Speed True HD Audio] on usb-:00:16.0-3/input2 What I've done so far: The device only has digital outputs. I've connected it to my AVR via optical link. For tests I'm using Audacious (output set to hw:2,0; bit depth 32 bit as suggested). The system is running Slackware 14.0 with kernel 3.2.29 (Alsa 1.0.24). Problems: * There is a blob when playback starts * 12MBit/s / full speed USB does not seem valid for me. I've thought USB Audio 2 uses high speed mode? * when trying to play a 24/96 track in Audacious I'm getting ALSA error: snd_pcm_hw_params_set_rate failed: Invalid argument. * using aplay on the same 24/96 file and plughw instead of hw leads to: cat /proc/asound/card2/pcm0p/sub0/hw_params access: MMAP_INTERLEAVED format: S32_LE subformat: STD channels: 2 rate: 48000 (48000/1) period_size: 6000 buffer_size: 24001 Interesting that plughw resamples to 48kHz! This is not what happens to my Schiit :-P if you look back in the discussion history, mind you I had no configuration files for alsa. Try to work with aplay -v and you should get immediate feedback without having to check files etc. If I recall aplay -v -D hw:2,0 with a 96/24 file should tell you that 24 bits is not supported and suggest some others that are. -- Chris Hermansen · clherman...@gmail.com C'est ma façon de parler. -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] Status of CM6631 USB
Daniel, Thorsten, list: On Tue, Dec 11, 2012 at 4:51 PM, Daniel Mack zon...@gmail.com wrote: On 11.12.2012 20:40, Thorsten Mühlfelder wrote: depth 32 bit as suggested). The system is running Slackware 14.0 with kernel 3.2.29 (Alsa 1.0.24). This kernel is *way* too old. Please try a 3.7 which has just been released. I would like to try frobnicating my Ubuntu-based setup to see how my results jibe (or don't) with Thorsten's, but I am about 10.000km from my music server until 20 December. So I will just have to watch. -- Chris Hermansen · clherman...@gmail.com C'est ma façon de parler. -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] Status of CM6631 USB
Try to work with aplay -v and you should get immediate feedback without having to check files etc. If I recall aplay -v -D hw:2,0 with a 96/24 file should tell you that 24 bits is not supported and suggest some others that are. Yes, aplay tells me: Available formats: - S16_LE - S32_LE But nothing about sampling rate. I'll try a newer kernel first... -- Thorsten Mühlfelder Salix OS: www.salixos.org -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] Status of CM6631 USB
The system is running Slackware 14.0 with kernel 3.2.29 (Alsa 1.0.24). This kernel is *way* too old. Please try a 3.7 which has just been released. OK, I've updated to 3.7.0. Now lsusb.py shows the device in high speed: 3-30d8c:0309 ef 2.00 480MBit/s 100mA 3IFs (CMEDIA USB2.0 High-Speed True HD Audio) Also it is possible to play files with 96 kHz sampling rate (S32_LE). Problems left: * There is a blob at the beginning of playback * each time playback format changes (16/44 to 24/96 and back) the sound is totally scrambled, but /proc/asound/card2/pcm0p/sub0/hw_params shows the correct playback format. Stop/start playback solves the problem. -- Thorsten Mühlfelder Salix OS: www.salixos.org -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] Status of CM6631 USB
I guess I was the last person discussing the use of this chip, in the
Schiit Bifrost
http://schiit.com/cart/index.php?main_page=product_infocPath=0products_id=7
Yes, it was your discussion about the Schiit.
The second is that hw does not handle the 24 bit word length, at
least in this context, necessitating the use of plughw to get to 32
bits.
Thanks for the information. So I need something like this?
pcm.usbplug {
type plug
slave {
pcm hw:1,0 # USB Audio device
format S32_LE
period_size 1024
buffer_size 4096
}
}
Daniel gave me a kernel patch he thought might help the first problem
and instructed me on its application, but that did not solve the
problem.
Yes, the discussion has ended without real solution. So this is why I've asked
here again.
As soon as the China device arrives I can test if it has the same issues like
your Schiit.
Greetings
--
Thorsten Mühlfelder
Salix OS: www.salixos.org
--
Keep yourself connected to Go Parallel:
INSIGHTS What's next for parallel hardware, programming and related areas?
Interviews and blogs by thought leaders keep you ahead of the curve.
http://goparallel.sourceforge.net
___
Alsa-user mailing list
Alsa-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] Status of CM6631 USB
Thorsten and list;
The second is that hw does not handle the 24 bit word length, at
least in this context, necessitating the use of plughw to get to 32
bits.
Thanks for the information. So I need something like this?
pcm.usbplug {
type plug
slave {
pcm hw:1,0 # USB Audio device
format S32_LE
period_size 1024
buffer_size 4096
}
}
In my case, I just used the plughw device that Alsa created
automagically, which in turn seemed to handle the word length
conversion just fine.
For clarity, alsaplay -D 'plughw:1,0' music.wav worked fine without
any manual configuration.
In your case, I guess you could be aiming for always converting to 32
bits, which would be OK I guess. In fact it might be worth
experimenting to see how the automatic rate adjustment works (or
doesn't). H.
Daniel gave me a kernel patch he thought might help the first problem
and instructed me on its application, but that did not solve the
problem.
Yes, the discussion has ended without real solution. So this is why I've
asked here again.
As soon as the China device arrives I can test if it has the same issues like
your Schiit.
Ok, if there's anything I can do let me know. I'm anxious to resolve
this matter!
--
Chris Hermansen · clherman...@gmail.com
C'est ma façon de parler.
--
Keep yourself connected to Go Parallel:
INSIGHTS What's next for parallel hardware, programming and related areas?
Interviews and blogs by thought leaders keep you ahead of the curve.
http://goparallel.sourceforge.net
___
Alsa-user mailing list
Alsa-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-user
