What hardware are u using for capture testing?
In the sdr-widget, the AKM ADC chip is run in master i2s mode. You need both the hardware and the i2s clocks from the ADC and the sdr-widget firmware for capture to work.
In the Audio-Widget branches of the firmware, the EPs have been re-ordered and reused, after some of the capture side codes were commented out.
So the only tested and working capture+playback combi is sdr-widget hardware with sdr-widget firmware.
Alex
In the sdr-widget, the AKM ADC chip is run in master i2s mode. You need both the hardware and the i2s clocks from the ADC and the sdr-widget firmware for capture to work.
In the Audio-Widget branches of the firmware, the EPs have been re-ordered and reused, after some of the capture side codes were commented out.
So the only tested and working capture+playback combi is sdr-widget hardware with sdr-widget firmware.
Alex
Hi Alex,
the hardware is OK, I checked the I2S signals, moreover (I use a Dragon to debug) I can see the samples in the buffers in memory. The problem is in the USB side.
Actually the endpoints for recording and feedback seem overlapped. When I start playback it looks like also recording is activated (I put some code to light up two leds based on the state of interface 2 alt 1 and interface 3 alt 1, and they seem to be activated at the same time). I use a hacked UAC2 driver in windows that has a spy tool, and I can see that only two endpoints are seen by the PC (altought the discovery is OK, I can dump the correct descriptors). The feedback endpoint has a wrong address, it has the address of recording endpoint. As both recording and playback start at the same time (although I start only one) on the feedback endpoint both type of buffers are received, and the recording arediscarded due to size limit violations.
Can you think of anythink that can cause the overlap of 0x81 and 0x83 endpoints? I checked a lot of sources, compared my code, but nothing. My main doubts are about the parts of the framework that were modified, I think I checked them but who knows ...
Yesterday evening I discovered some minor problem about endpoint descriptors (not in my code, in all the sources that I've seen), actually a field is missing (with respect to the UAC2 specification) so struct size is smaller. I added the field, compiled, it works, but no behaviour change.
But I remember browsing the sources and discovering an endpoint initialization routine that actually jumps over the structs based on struct size, and this can be fooled by size differences.
Any idea about how the endpoints can overlap? Any idea about initialization routins tha I can check?
Thank you for your help anyway.
the hardware is OK, I checked the I2S signals, moreover (I use a Dragon to debug) I can see the samples in the buffers in memory. The problem is in the USB side.
Actually the endpoints for recording and feedback seem overlapped. When I start playback it looks like also recording is activated (I put some code to light up two leds based on the state of interface 2 alt 1 and interface 3 alt 1, and they seem to be activated at the same time). I use a hacked UAC2 driver in windows that has a spy tool, and I can see that only two endpoints are seen by the PC (altought the discovery is OK, I can dump the correct descriptors). The feedback endpoint has a wrong address, it has the address of recording endpoint. As both recording and playback start at the same time (although I start only one) on the feedback endpoint both type of buffers are received, and the recording arediscarded due to size limit violations.
Can you think of anythink that can cause the overlap of 0x81 and 0x83 endpoints? I checked a lot of sources, compared my code, but nothing. My main doubts are about the parts of the framework that were modified, I think I checked them but who knows ...
Yesterday evening I discovered some minor problem about endpoint descriptors (not in my code, in all the sources that I've seen), actually a field is missing (with respect to the UAC2 specification) so struct size is smaller. I added the field, compiled, it works, but no behaviour change.
But I remember browsing the sources and discovering an endpoint initialization routine that actually jumps over the structs based on struct size, and this can be fooled by size differences.
Any idea about how the endpoints can overlap? Any idea about initialization routins tha I can check?
Thank you for your help anyway.
Hi
Any chance of a recapture for a recent arrival and a interested bystander, I have a wish to
record 4 channels 24 bit Microphone level input.
- Pointer to firmware with recording working.
- pointer to Nikolay's driver
- The easiest way to Aquire a Audio Widget card.
- Any pointers to 4 channel ADC designs.
Sorry if I sound like "I Want It All Now" without any work from me
Best Regards
Bosse
Any chance of a recapture for a recent arrival and a interested bystander, I have a wish to
record 4 channels 24 bit Microphone level input.
- Pointer to firmware with recording working.
- pointer to Nikolay's driver
- The easiest way to Aquire a Audio Widget card.
- Any pointers to 4 channel ADC designs.
Sorry if I sound like "I Want It All Now" without any work from me
Best Regards
Bosse
This is the usb descriptors of the audio-widget I have, in uac2:
0x81 is the rate feedback EP. 0x02 is the playback EP. No overlap.
This is the usb descriptor of my sdr-widget:
0x81 is the capture EP. 0x02 is the playback EP. 0x83 is the rate feedback EP.
Let me emphasize again that sdr-widget has both capture and playback, and audio-widget has playback only.
It is possible (or indeed likely) that there might be some sdr-widget code for capture that has not been commented out in audio-widget firmware. But in audio-widget firmware, capture is not meant to be enabled (so far).
I have actually tried to add back capture to the audio-widget firmware but failed. The capture part worked but the playback was not working at any speed higher than 48khz. The sdr-widget and audio-widget branches have diverged too much for an easy merge. There are many differences. E.g. the audio-widget is now 32 bits, but the sdr-widget remains at 24 bits (as the ADC is a 24 bit device). The HID codes in audio-widget may not be compatible with the sdr-widget codes. The cpu horsepower may be exceeded when there are capture, playback, HID EP's to service. etc.
So I have been incrementally adding functions/features in the audio-widget-experimental branch to the sdr-widget branch (which is master), but not wholesale merge.
Alex
Hi Starn02,
In many (? most, including Nikolay's driver and commercial drivers) uac2 drivers, they will AUTOMATICALLY use the capture EP as the timing source for playback, EVEN when there is a separate explicit FB EP, which will be ignored.
This is a feature/function of the uac2 drivers. Please read the driver documentations (if any). There may be a way to defeat it, but I'm not familiar with it.
Alex
Hi Starn02,
Also note that if you are using the audio-widget firmware, the capture descriptors are still at 24 bits, but the playback descriptors are at 32 bits. They will NOT be compatible.
That's why in the master branch, sdr-widget firrmware, both capture and playback are still at 24 bits.
Alex
Also note that if you are using the audio-widget firmware, the capture descriptors are still at 24 bits, but the playback descriptors are at 32 bits. They will NOT be compatible.
That's why in the master branch, sdr-widget firrmware, both capture and playback are still at 24 bits.
Alex
Hi all,
The fact that in many uac2 drivers the capture EP will be used for timing of playback stream even in the presence of an explicit FB EP, explains some issues that some users have experienced under certain conditions:
1. running audio-widget firmware with audio-widget hardware - no problems;
2. running audio-widget firmware with sdr-widget hardware - no problems. (as the rate FB EP is used.)
3. running sdr-widget firmware with sdr-widget hardware under Linux - no problems.
4. running sdr-widget firmware with sdr-widget hardware under Nikolay's Windows driver - metallic sound during playback after some minutes (as the FB EP is not used. the driver uses the capture EP for timing.)
These issues were reported by some users, but not experienced by others and not by me. I suspect it is because the timing difference between the sdr-widget and the PC used by those users are too great for the uac2 driver to sync. If the timing difference is small, then the driver can sync the two clocks and there is no metallic sound.
Improvements to the rate feedback algorithm in the FB EP, by Borge (and Nikolay) will NOT help as the feedback source is the capture EP.
Obviously the Linux uac2 driver is able to sync. So may be some improvements to Nikolay's driver will help.
If all these sound very confusing, please remember that Borge and Nikolay have things worked out very well for PLAYBACK of audio-widgets.
It is when people try to do BOTH capture and playback that things get more complicated. It works very well with sdr-widget (that we use in amateur ratio projects) under certain conditions (but not all conditions). We are still working on these issues.
Alex
The fact that in many uac2 drivers the capture EP will be used for timing of playback stream even in the presence of an explicit FB EP, explains some issues that some users have experienced under certain conditions:
1. running audio-widget firmware with audio-widget hardware - no problems;
2. running audio-widget firmware with sdr-widget hardware - no problems. (as the rate FB EP is used.)
3. running sdr-widget firmware with sdr-widget hardware under Linux - no problems.
4. running sdr-widget firmware with sdr-widget hardware under Nikolay's Windows driver - metallic sound during playback after some minutes (as the FB EP is not used. the driver uses the capture EP for timing.)
These issues were reported by some users, but not experienced by others and not by me. I suspect it is because the timing difference between the sdr-widget and the PC used by those users are too great for the uac2 driver to sync. If the timing difference is small, then the driver can sync the two clocks and there is no metallic sound.
Improvements to the rate feedback algorithm in the FB EP, by Borge (and Nikolay) will NOT help as the feedback source is the capture EP.
Obviously the Linux uac2 driver is able to sync. So may be some improvements to Nikolay's driver will help.
If all these sound very confusing, please remember that Borge and Nikolay have things worked out very well for PLAYBACK of audio-widgets.
It is when people try to do BOTH capture and playback that things get more complicated. It works very well with sdr-widget (that we use in amateur ratio projects) under certain conditions (but not all conditions). We are still working on these issues.
Alex
Hi Alex,
I have modified the endpoints to work with 32 bit, they work OK.
And I have tried other changes in endpoint numbering, for instance even exchanging the index of feedback and rec endpoints the behaviour is the same (altough the "spy tool" reports a different address.
I understand your suggestions , and will try again to check source codes.
Anyway, how can it be that when I start playback both interface 2 alt 1 and interface 3 alt 1 are activated? One of them is for playback and one for recording. In spite of this the behaviour is constant, never seen a different one with all the versions that I tried.
Thank you anyway.
I have modified the endpoints to work with 32 bit, they work OK.
And I have tried other changes in endpoint numbering, for instance even exchanging the index of feedback and rec endpoints the behaviour is the same (altough the "spy tool" reports a different address.
I understand your suggestions , and will try again to check source codes.
Anyway, how can it be that when I start playback both interface 2 alt 1 and interface 3 alt 1 are activated? One of them is for playback and one for recording. In spite of this the behaviour is constant, never seen a different one with all the versions that I tried.
Thank you anyway.
Uac2 compliant
U can use Nikolay's driver with it.
The capture performance is excellent.
Alex
Can you point to a schematic with the necessary clues for the connections?
Hi Alex,
unfortunately I don't have a github ID. I use the Atmel Studio 6 ide, and for the source browsing I actually use internet ...
Anyway, looking back at your recent posts, I can see what's the situation of usb descriptors in the two cases (sdr and audio).
Also in my case the usb descriptors are reported OK, I dumped them with the Thesycon tdd tool and they are ok. The addresses of endpoints are correctly set to 0x81, 0x02 and ox83 (rec, play and feedback).
It's when the interface is in use that I see the strange behaviour of both alternate 1 interfaces (2 = rec, 3 = play) activated at the same time when only playing ....
Anyway, I will make another check of the sdr-widget branch code and compare the usb parts with my source. I hope I can catch the problem ...
unfortunately I don't have a github ID. I use the Atmel Studio 6 ide, and for the source browsing I actually use internet ...
Anyway, looking back at your recent posts, I can see what's the situation of usb descriptors in the two cases (sdr and audio).
Also in my case the usb descriptors are reported OK, I dumped them with the Thesycon tdd tool and they are ok. The addresses of endpoints are correctly set to 0x81, 0x02 and ox83 (rec, play and feedback).
It's when the interface is in use that I see the strange behaviour of both alternate 1 interfaces (2 = rec, 3 = play) activated at the same time when only playing ....
Anyway, I will make another check of the sdr-widget branch code and compare the usb parts with my source. I hope I can catch the problem ...
Latest news about recording
After all the test and source compares ... I decided that I had to install Linux and try a different OS. My doubt was about the effectiveness of the driver that I have on windows ....
So I installed Ubuntu 12.4, plugged the board and ... voilà, playback is OK , but also recording is working (I get strange samples, but that's a different problem). Even the leds that I installed work properly, and only one is active when the relative alternate setting is selected (I have a green led for play and a red one for REC).
So it looks like either the UAC2 driver under windows is working only for playback (but it's strange, it is intended also for adc/dac boards) or the actual descriptor layout is OK for Linux but not completely ok for windows .. or at least for that driver.
I need to work under windows, but I have no alternatives for the driver.
I will try to arrange the descriptors in another way, maybe by having two alternate settings for interface 2 (1 for rec, one for playback). I remember I saw a version of the firmware that actually had alternate 2 in #defines (although it was not used in practice).
If somebody is more expert than me ... what's the usual layout when you need two AS interfaces, 1 for rec and 1 for play?
It's better to have one interface with alternates 0,1 and 2 or to separate (like in most sources that I saw) in two groups (interface 2 alt 0 and 1, and interface 3 alt 0 and 1)?
After all the test and source compares ... I decided that I had to install Linux and try a different OS. My doubt was about the effectiveness of the driver that I have on windows ....
So I installed Ubuntu 12.4, plugged the board and ... voilà, playback is OK , but also recording is working (I get strange samples, but that's a different problem). Even the leds that I installed work properly, and only one is active when the relative alternate setting is selected (I have a green led for play and a red one for REC).
So it looks like either the UAC2 driver under windows is working only for playback (but it's strange, it is intended also for adc/dac boards) or the actual descriptor layout is OK for Linux but not completely ok for windows .. or at least for that driver.
I need to work under windows, but I have no alternatives for the driver.
I will try to arrange the descriptors in another way, maybe by having two alternate settings for interface 2 (1 for rec, one for playback). I remember I saw a version of the firmware that actually had alternate 2 in #defines (although it was not used in practice).
If somebody is more expert than me ... what's the usual layout when you need two AS interfaces, 1 for rec and 1 for play?
It's better to have one interface with alternates 0,1 and 2 or to separate (like in most sources that I saw) in two groups (interface 2 alt 0 and 1, and interface 3 alt 0 and 1)?
See George's archive:
http://www.yoyodyneconsulting.ca/downloads/General/DOCS-SDR-Widget-kit.tar.bz2
The relevant schematics is in that document archive, copied here:
https://dl.dropbox.com/u/8145461/AK5394-3.00.pdf
Alex
Last edited:
Hi Demian,
It looks great, it should have very low noise and low output impedance.
Have anyone tried it? Are there any further incarnations of it?
You first find out the capture device:
$ arecord -l
Suppose it is card 1, then the alsa name of that hardware is hw:1.
To record if it is using sdr-widget firmware, with 24 bit:
$ arecord -D hw:1 -c 2 -r 192000 -f S24_3LE > test.wav
If you are using 32 bits, then the format will be:
-f S32_LE
etc.
Alex
Hi
Any chance of a recapture for a recent arrival and a interested bystander, I have a wish to
record 4 channels 24 bit Microphone level input.
- Pointer to firmware with recording working.
- pointer to Nikolay's driver
- The easiest way to Aquire a Audio Widget card.
- Any pointers to 4 channel ADC designs.
Sorry if I sound like "I Want It All Now" without any work from me
Best Regards
Bosse
Q N K T C USB-I2S Module and Analog Board
https://github.com/amontefusco/sdr-widget/blob/audio-widget-experimental/AW_readme.txt
http://www.yoyodyneconsulting.ca/pages/Audio_Hardware.html