Async USB Dac Experiments - testers wanted...

[Jeff Flowerday]

Switched to async usb last night on the .5 kernel. Played a 176.4 Neil Young had a drop out on one song.

Upgraded to your .7 test kernel, played the whole album through no drop outs. The drop out might have been a one time thing, like I said I had just switched to Async USB last night.



I do get a second drop out at the beginning of the first song on a sample rate change. Is that the nature of the beast, or is it something that might be addressed? But now I also can't remember if it happened on the stock SPDIF out either. I'm a bad tester!


Hiface 2

[Jeff Flowerday]

Switched to async usb last night on the .5 kernel. Played a 176.4 Neil Young had a drop out on one song.

Upgraded to your .7 test kernel, played the whole album through no drop outs. The drop out might have been a one time thing, like I said I had just switched to Async USB last night.



I do get a second drop out at the beginning of the first song on a sample rate change. Is that the nature of the beast, or is it something that might be addressed? But now I also can't remember if it happened on the stock SPDIF out either. I'm a bad tester!


Hiface 2

Ok I think the drop out was related to not enough juice being supplied to the hiface. Got home tonight and the touch crashed as soon as I hit play. I backed EDO out and forced installed 7.7.2 and then did a reset on top. Reinstalled EDO. Got audio cutting out at 172 sample rate again.

Gave the high face more juice with a Y usb cable and hub, and drop outs went away.

[JIJ3]

I need to try this again - according to the imx35 reference manual there is a divider which should be able to be programmed to change the clock rate, but when I tried it didn't appear to work. I don't have access to test gear to look at the lock rates coming out of the imx35 soc chip so would be interested in trying some changes if other people can test the impact on the clock outputs.

I would be interested in your reading of 46.4.2 of the processor reference manual - (I think available from the freescale site) - do you think changing the div2 stage would result in the right clocks?

With kernal 5, 192K files play at 1/2 speed. They are not downsampled by the server. With kernal 6, they play at correct speed, but are downsampled by the server. Does kernal 5 alter this DIV2 setting to divide the clocks by 2? If so, that may be the problem. My reading of this section is that DIV2 should be set to 0.

[Triode]

With kernal 5, 192K files play at 1/2 speed. They are not downsampled by the server. With kernal 6, they play at correct speed, but are downsampled by the server. Does kernal 5 alter this DIV2 setting to divide the clocks by 2? If so, that may be the problem. My reading of this section is that DIV2 should be set to 0.

It defaults to and is set to 1 for all cases - kernel #5 should have set it to 0 for the 192k case but it doesn't seem to work. I need to look at this again.

[JIJ3]

It defaults to and is set to 1 for all cases - kernel #5 should have set it to 0 for the 192k case but it doesn't seem to work. I need to look at this again.

What happens if you leave it at 1 for 192K?
Edit: I guess that would divide it down even further, to 48K. I see why you wanted to change this bit to 0. I assume the input clock is 24.576 when playing 192K files.

Any way to verify how bits are actually set in this chip?

[JIJ3]

Triode, thinking some more about this.

If DIV2 is really set to 1 for both 48K and 96K, then PM must be different for these two cases (unless external logic changes the master clock rate, which would seem silly). I assume the master clock for 48K, 96K, (and therefore 192K) is 24.476 Mhz. Then 48K requires a divide by 16 to generate a 1.5298 Mhz bit clock, 96 K would require a divide by 8, (and 192K a divide by 4). If DIV2 is set to one for 48K and 96K, then PV would have to be 3 for 48K, 1 for 96K (and zero for 192K, if DIV2 stayed at 1).

I know you're very busy with the USB work, but when you get a chance you might want to look closely at the DIV2 and PM bit settings for all cases.

Jack

[diego]

Hi there

TE8802L worked with EDO app when using it with a USB-input-module of audio-gd that is flashed with a test firmware.

However, it does only work correctly with 16b/44.1k - files. Trying with 24b/96K - files crackled.

Details are in this post:
http://forums.slimdevices.com/showth...l=1#post707174

What is important here:

As an alternative, I wanted to try the procedure in Triods Experimental Kernels, so I tried the procedure of this thread's first post.

However, I found only the Kernel Update plugin. The "USB Audio Ouput" - Plugin was just not there (even though obviously I had correctly entered the LMS Web settings).

I supposed, that this "USB Audio Ouput" had been replaced by this EDO - app. So I tried installing both: Kernel updater and EDO.

Kernel updater showed Kernel #7 and Kernel #8. But when trying to install them, the download did not even start and I got the message that the update failed. I assume, they were not found on the server or the server was down or something.

I also tried installing only Kernel Updater alone (after a factory reset of course), assuming that maybe, both apps were together in one now. However, kernel update would not work anyway (only with the EDO-app that did it as expected, but there is no choice on experimental Kernels).

@TRIODE: How can I help you, developping the EDO-app, in order to work with TE8802? Can I send you any useful logs or screenshots...? Unfortunately I do not have permission to send you the experimental firmware I got.

Best regards and thanks again to Triode for developping this.

[Triode]

USB test kernel #9

There is a patch on the alsa development list which looks like it may be relavent to the Teac UD-H01 support. It looks like this patch is speculative and unproven (i.e. no one has responded to the patch author saying it works...) However I've applied this patch to the touch kernel and hosted as Usb Test Kernel #9

If you have a Teac UD-H01 or other device then you may want to try it. It may also be worth trying for other devices using the same interface chip.

To try:

1) Install EDO
2) Add my usb test repo to the additional repositories box at the bottom of the LMS plugins page:

http://triodeapplets.googlecode.com/svn/trunk/usbtestrepo.xml

3) Install the Kernel Updater app
4) Go to settings > advanced > kernel updater and select and install kernel #9

Please post what demsg says here together with whether you are able to select the usb output with this. I've no idea if it works, but the bug fixed by the patch does seem a reasonable bug to fix.

[diego]

Thanks Triode, this gives again hope!

TEAC uses TE8802. However, I suspect, that a matching firmware is needed, to have it even "seen" by the SBT. At least, this is my experience. I use a TE8802-audio-gd-Digital Interface. When I have the standard firmware (made for win and mac) flashed onto the module, and I connect that to the Touch, the interface just does not show up as available sound card in the EDO-list of available digital outputs. I suspect however, that this is more a "declaratory" issue, than a really different firmware programming.

Anyway, I will try it out as soon as I can and let you know, if it worked, with my audio-gd, that has this "linux test firmware" flashed onto it.

PS The TE8802-vendor does not reply anymore to my mails, even though I have written a couple of times.

USB test kernel #9

There is a patch on the alsa development list which looks like it may be relavent to the Teac UD-H01 support. It looks like this patch is speculative and unproven (i.e. no one has responded to the patch author saying it works...) However I've applied this patch to the touch kernel and hosted as Usb Test Kernel #9

If you have a Teac UD-H01 or other device then you may want to try it. It may also be worth trying for other devices using the same interface chip.

To try:

1) Install EDO
2) Add my usb test repo to the additional repositories box at the bottom of the LMS plugins page:

http://triodeapplets.googlecode.com/svn/trunk/usbtestrepo.xml

3) Install the Kernel Updater app
4) Go to settings > advanced > kernel updater and select and install kernel #9

Please post what demsg says here together with whether you are able to select the usb output with this. I've no idea if it works, but the bug fixed by the patch does seem a reasonable bug to fix.

[Triode]

Thanks Triode, this gives again hope!

TEAC uses TE8802. However, I suspect, that a matching firmware is needed, to have it even "seen" by the SBT. At least, this is my experience. I use a TE8802-audio-gd-Digital Interface. When I have the standard firmware (made for win and mac) flashed onto the module, and I connect that to the Touch, the interface just does not show up as available sound card in the EDO-list of available digital outputs. I suspect however, that this is more a "declaratory" issue, than a really different firmware programming.

Anyway, I will try it out as soon as I can and let you know, if it worked, with my audio-gd, that has this "linux test firmware" flashed onto it.

PS The TE8802-vendor does not reply anymore to my mails, even though I have written a couple of times.

Did you look at the dmesg log - its may be that it is the same error as the Teac - depends on who writes the firmware. Anyway this looks to resolve a bug which the Teac definitely suffers from as far as the alsa list is concerned and if you are hitting the same problem may improve it..

I'm wondering if your linux test firmware has other bugs in it for other sample rates. So try this with the original firmware too and look at the dmesg for each case.