Re: [alsa-devel] USB asynchronous mode feedback format
Am Donnerstag, 14. Oktober 2010, 13:15:45 schrieb Alex:
Great to hear that ASYNC OUT with rate feedback is working for u now :-)
Btw, are u using 12.13 format for Linux ? U can try with OSX snow leopard, which can understand 10.14 and 16.16. Apply Clemens' patch and linux can understand all formats - but users will have to wait for kernel 2.6.37 !
I have implemented a sophisticated rate feedback with ping pong audio buffer, calculation of gap between USB data and i2s data, determining whether gap is increasing or decreasing etc.
One more question on the feedback: In your project you fo 10.14 for Full Speed devices (which mine is - the AT91SAM7A3 can't do High Speed) and 12.13 for highspeed. Why do you distinguish that way? Is your device initialised in High Speed mode whenever it's connected to a Linux host?
Regards, Julian
On Thu, 2010-10-14 at 13:58 +0200, Julian Scheel wrote:
One more question on the feedback: In your project you fo 10.14 for Full Speed devices (which mine is - the AT91SAM7A3 can't do High Speed) and 12.13 for highspeed. Why do you distinguish that way? Is your device initialised in High Speed mode whenever it's connected to a Linux host?
I started off with the assumption that with UAC1 in FS, the specs says 10.14. However, I'm running the widget in HS (but still UAC1), so according to USB2.0 spec, the ISO feedback should be in 16.16 format. Later I found out that Linux uses 12.13 (for whatever reasons), so I changed the HS format to 12.13, leaving the FS format at 10.14.
My project uses the AT32UC3A3, which can operate it both HS and FS. So it can enumerate to be either a HS or a FS device depending on the PC/ USB Hub's capabilities. So the firmware has to cater to both cases. We are also doing compatibility testing with Vista and Win7 (WinXP does not support rate feedback). So we need to test HS and FS as well. OSX can accept either 10.14 or 16.16 format, depending on whether the firmware sends it 3 bytes or 4 bytes in the feedback pipe, so it will work with FS or HS.
We are also developing a version of the firmware for UAC2. So we will have to figure out what format to use for UAC2 as well - most likely 16.16. However, for Linux, we will need to wait for Clemens' patch to reach the distributions. btw, there are other bugs in the alsa UAC2 driver that Daniel has fixed, but the patches are not in the 2.6.35 kernel - probably in 2.6.36 or 2.6.37. So currently we have workarounds in the widget firmware for UAC2.
There are other incompatibilities as well. For example, my current UAC1 firmware has workable mute controls when running in Windows. But in Linux, alsamixer cannot interpret the mute/volume controls. The UAC2 controls are interpreted correctly by alsamixer, though.
I looked at your scope traces. DATA seems to be valid at the falling edges of SCLK. According to i2S specs, they are supposed to be valid at the rising edges. The relationship between LRCK and DATA looks OK (ie one SCLK delay from the LRCK edge), though.
Do you get any analog output at all from the DAC? Any noise at all?
Alex
Am Donnerstag, 14. Oktober 2010, 17:28:19 schrieb Alex Lee:
On Thu, 2010-10-14 at 13:58 +0200, Julian Scheel wrote:
One more question on the feedback: In your project you fo 10.14 for Full Speed devices (which mine is - the AT91SAM7A3 can't do High Speed) and 12.13 for highspeed. Why do you distinguish that way? Is your device initialised in High Speed mode whenever it's connected to a Linux host?
I started off with the assumption that with UAC1 in FS, the specs says 10.14. However, I'm running the widget in HS (but still UAC1), so according to USB2.0 spec, the ISO feedback should be in 16.16 format. Later I found out that Linux uses 12.13 (for whatever reasons), so I changed the HS format to 12.13, leaving the FS format at 10.14.
Ah ok, I see... Linux uses 12.13 in any case though? (Without the new patch of course)
My project uses the AT32UC3A3, which can operate it both HS and FS. So it can enumerate to be either a HS or a FS device depending on the PC/ USB Hub's capabilities. So the firmware has to cater to both cases. We are also doing compatibility testing with Vista and Win7 (WinXP does not support rate feedback). So we need to test HS and FS as well. OSX can accept either 10.14 or 16.16 format, depending on whether the firmware sends it 3 bytes or 4 bytes in the feedback pipe, so it will work with FS or HS.
Ok, being compatible with al OSes seems to be a non-trivial task...
We are also developing a version of the firmware for UAC2. So we will have to figure out what format to use for UAC2 as well - most likely 16.16. However, for Linux, we will need to wait for Clemens' patch to reach the distributions. btw, there are other bugs in the alsa UAC2 driver that Daniel has fixed, but the patches are not in the 2.6.35 kernel - probably in 2.6.36 or 2.6.37. So currently we have workarounds in the widget firmware for UAC2.
Good to know. So far I only do UAC1, but for 192kHz I will have to switch to UAC2... May I come back to you with some questions about UAC2 then?
There are other incompatibilities as well. For example, my current UAC1 firmware has workable mute controls when running in Windows. But in Linux, alsamixer cannot interpret the mute/volume controls. The UAC2 controls are interpreted correctly by alsamixer, though.
Odd... I only have one control so far, a PCM mute control... That one seems to work well in Linux.
I looked at your scope traces. DATA seems to be valid at the falling edges of SCLK. According to i2S specs, they are supposed to be valid at the rising edges. The relationship between LRCK and DATA looks OK (ie one SCLK delay from the LRCK edge), though.
Ok, fixed both issues. Uploaded a new capture: http://jusst.de/files/i2s_plot2.png This seems to be ok for what I can say... Do you agree?
Do you get any analog output at all from the DAC? Any noise at all?
Actually the module has a constant DC voltage of between 1.2 V on R+, 1.4 V on L+ outputs and between 2.2 V on R- and 2.6V on L- output.... Which actually is really odd as the I/V stage has DC block capacitors in it... This is the schematic of the DAC module: http://www.twistedpearaudio.com/docs/digital/cod_schematic.pdf
Regards, Julian
Am Donnerstag, 14. Oktober 2010, 17:28:19 schrieb Alex Lee:
On Thu, 2010-10-14 at 13:58 +0200, Julian Scheel wrote:
One more question on the feedback: In your project you fo 10.14 for Full Speed devices (which mine is - the AT91SAM7A3 can't do High Speed) and 12.13 for highspeed. Why do you distinguish that way? Is your device initialised in High Speed mode whenever it's connected to a Linux host?
I started off with the assumption that with UAC1 in FS, the specs says 10.14. However, I'm running the widget in HS (but still UAC1), so according to USB2.0 spec, the ISO feedback should be in 16.16 format. Later I found out that Linux uses 12.13 (for whatever reasons), so I changed the HS format to 12.13, leaving the FS format at 10.14.
My project uses the AT32UC3A3, which can operate it both HS and FS. So it can enumerate to be either a HS or a FS device depending on the PC/ USB Hub's capabilities. So the firmware has to cater to both cases. We are also doing compatibility testing with Vista and Win7 (WinXP does not support rate feedback). So we need to test HS and FS as well. OSX can accept either 10.14 or 16.16 format, depending on whether the firmware sends it 3 bytes or 4 bytes in the feedback pipe, so it will work with FS or HS.
Besides my I2S/DAC troubles, I still seem to have some problem with the async mode. Actually my buffers are permanently overflowing (not slightly, but very extreme). So far I do not regulate the feedback data, but send a constant value of 48 - As I expect 48 samples per USB frame.
So my data is (48<<13):
char data[4]; data[0] = 0x00; data[1] = 0x06; data[2] = 0x00; data[3] = 0x00;
AUDDSpeakerDriver_WriteFeedback(data, 4, (TransferCallback)FeedbackSent, NULL);
Whenever the feedback was sent (ie it was queried by the host), this method is called again and it sends the feedback again. Is this ok in general or is there some basic problem with this feedback style?
Regards, Julian
On Fri, 2010-10-15 at 14:08 +0200, Julian Scheel wrote:
Besides my I2S/DAC troubles, I still seem to have some problem with the async mode. Actually my buffers are permanently overflowing (not slightly, but very extreme). So far I do not regulate the feedback data, but send a constant value of 48 - As I expect 48 samples per USB frame.
So my data is (48<<13):
char data[4]; data[0] = 0x00; data[1] = 0x06; data[2] = 0x00; data[3] = 0x00; AUDDSpeakerDriver_WriteFeedback(data, 4, (TransferCallback)FeedbackSent, NULL);Whenever the feedback was sent (ie it was queried by the host), this method is called again and it sends the feedback again. Is this ok in general or is there some basic problem with this feedback style?
UAC data should be Big Endian. Send the LSB byte first.
Alex
Am Freitag, 15. Oktober 2010, 14:52:15 schrieb Alex Lee:
So my data is (48<<13): char data[4]; data[0] = 0x00; data[1] = 0x06; data[2] = 0x00; data[3] = 0x00;
AUDDSpeakerDriver_WriteFeedback(data, 4, (TransferCallback)FeedbackSent, NULL);Whenever the feedback was sent (ie it was queried by the host), this method is called again and it sends the feedback again. Is this ok in general or is there some basic problem with this feedback style?
UAC data should be Big Endian. Send the LSB byte first.
Ah right, thanks. Well now I swapped data[1] and data[2]. When monitoring the amount of data I get per read, it is constant at 192bytes, which would be expected for feedback ratio of 48, right? But if I have 0x06 to 0x07 for example I do still get exactly 192bytes per read, shouldn't I get less data in that case? (I always try to read up to MAXPACKETSIZE which is 512, btw)
Regards, Julian
On Fri, 2010-10-15 at 15:04 +0200, Julian Scheel wrote:
Ah right, thanks. Well now I swapped data[1] and data[2]. When monitoring the amount of data I get per read, it is constant at 192bytes, which would be expected for feedback ratio of 48, right? But if I have 0x06 to 0x07 for example I do still get exactly 192bytes per read, shouldn't I get less data in that case? (I always try to read up to MAXPACKETSIZE which is 512, btw)
Suggest:
(1) The feedback rate has to fall withing +/- 10% of the nominal rate. Otherwise it is ignored.
(2) You need to find out exactly how many samples the host sends you. Look at my sdr-widget code, for example. Then you read what the host sends you.
(3) Do a > dmesg | tail after unplugging and plugging your USB device in. Then you can see whether there are any errors in your syncpipe
btw, what is your Linux kernel version?
Alex
Am Freitag, 15. Oktober 2010, 15:31:50 schrieb Alex Lee:
On Fri, 2010-10-15 at 15:04 +0200, Julian Scheel wrote:
Ah right, thanks. Well now I swapped data[1] and data[2]. When monitoring the amount of data I get per read, it is constant at 192bytes, which would be expected for feedback ratio of 48, right? But if I have 0x06 to 0x07 for example I do still get exactly 192bytes per read, shouldn't I get less data in that case? (I always try to read up to MAXPACKETSIZE which is 512, btw)
Suggest:
(1) The feedback rate has to fall withing +/- 10% of the nominal rate. Otherwise it is ignored.
Ok. I tried it with 0x5e, which should be 47. Still same amount of data being fed in.
(2) You need to find out exactly how many samples the host sends you. Look at my sdr-widget code, for example. Then you read what the host sends you.
Actually I checked your code and it seems quite similiar to mine. I use the at91lib for USB stuff, so the capsulation is a bit different. I call a function USBD_Read, which does read up to the given amount of bytes (in my case max 512) or the receivement of a short packet. Each packet I receive by reading with USBD_Read is exactly 192bytes long. As I won't be able to get more than 1 packet per USB frame, I should be receiving 1000 * 192bytes per second. No matter what I write to the feedback pipe. which is kinda odd.
(3) Do a > dmesg | tail after unplugging and plugging your USB device in. Then you can see whether there are any errors in your syncpipe
Don't see any syncpipe related errors. Only thing I see is: usb 1-1.3: new full speed USB device using ehci_hcd and address 11 11:1:1: endpoint lacks sample rate attribute bit, cannot set. 11:1:1: endpoint lacks sample rate attribute bit, cannot set.
Does not seem to be feedback related... Although it would be nice to know, what's wrong there?
btw, what is your Linux kernel version?
2.6.35.7-1 (archlinux, 32bit)
Is there any way to get some more verbosity out of alsa drivers? To check if it really receives the feedback information at all.
Regards, Julian
Julian Scheel wrote:
11:1:1: endpoint lacks sample rate attribute bit, cannot set.
Does not seem to be feedback related... Although it would be nice to know, what's wrong there?
What's wrong is 1) that the driver complains about something that isn't wrong, and 2) that you're using a driver more than three months old, which is when I killed that message. ;-)
Is there any way to get some more verbosity out of alsa drivers? To check if it really receives the feedback information at all.
grep "Momentary freq" /proc/asounc/cardX/stream0
Or put a log message into retire_playback_sync_urb*().
Regards, Clemens
Am Freitag, 15. Oktober 2010, 16:34:31 schrieb Clemens Ladisch:
Julian Scheel wrote:
11:1:1: endpoint lacks sample rate attribute bit, cannot set.
Does not seem to be feedback related... Although it would be nice to know, what's wrong there?
What's wrong is
- that the driver complains about something that isn't wrong, and
- that you're using a driver more than three months old, which is when I killed that message. ;-)
Ok, good to know (c:
Is there any way to get some more verbosity out of alsa drivers? To check if it really receives the feedback information at all.
grep "Momentary freq" /proc/asounc/cardX/stream0
Or put a log message into retire_playback_sync_urb*().
Momemtary freq in stream0 always stays at 48000 (0x30). So feedback seems to be ignored?
On Fri, 2010-10-15 at 16:24 +0200, Julian Scheel wrote:
Don't see any syncpipe related errors. Only thing I see is: usb 1-1.3: new full speed USB device using ehci_hcd and address 11 11:1:1: endpoint lacks sample rate attribute bit, cannot set. 11:1:1: endpoint lacks sample rate attribute bit, cannot set.
Does not seem to be feedback related... Although it would be nice to know, what's wrong there?
You probably need to fix that sample rate attribute bit for rate feedback to work.
It is in the bmAttribute of the //Audio endpoint specific descriptor #define AUDIO_EP_ATRIBUTES UAC_EP_CS_ATTR_SAMPLE_RATE // sampling freq, no pitch, no pading
#define AUDIO_EP_DELAY_UNIT 0x00 // Unused #define AUDIO_EP_LOCK_DELAY 0x0000 // Unused
Alex
Am Freitag, 15. Oktober 2010, 16:41:38 schrieb Alex Lee:
On Fri, 2010-10-15 at 16:24 +0200, Julian Scheel wrote:
Don't see any syncpipe related errors. Only thing I see is: usb 1-1.3: new full speed USB device using ehci_hcd and address 11 11:1:1: endpoint lacks sample rate attribute bit, cannot set. 11:1:1: endpoint lacks sample rate attribute bit, cannot set.
Does not seem to be feedback related... Although it would be nice to know, what's wrong there?
You probably need to fix that sample rate attribute bit for rate feedback to work.
It is in the bmAttribute of the //Audio endpoint specific descriptor #define AUDIO_EP_ATRIBUTES UAC_EP_CS_ATTR_SAMPLE_RATE // sampling freq, no pitch, no pading
#define AUDIO_EP_DELAY_UNIT 0x00 // Unused #define AUDIO_EP_LOCK_DELAY 0x0000 // Unused
You mean in the class specific endpoint descriptor for the audio streaming endpoint? Actually I added it there (bmAttributes = 0x01), but this stops alsa from detecting the device at all. Attaches is the new lsusb out.
Regards, Julian
Am Freitag, 15. Oktober 2010, 19:16:25 schrieb Julian Scheel:
Am Freitag, 15. Oktober 2010, 16:41:38 schrieb Alex Lee:
On Fri, 2010-10-15 at 16:24 +0200, Julian Scheel wrote:
Don't see any syncpipe related errors. Only thing I see is: usb 1-1.3: new full speed USB device using ehci_hcd and address 11 11:1:1: endpoint lacks sample rate attribute bit, cannot set. 11:1:1: endpoint lacks sample rate attribute bit, cannot set.
Does not seem to be feedback related... Although it would be nice to know, what's wrong there?
You probably need to fix that sample rate attribute bit for rate feedback to work.
It is in the bmAttribute of the
//Audio endpoint specific descriptor
#define AUDIO_EP_ATRIBUTES UAC_EP_CS_ATTR_SAMPLE_RATE // sampling freq, no pitch, no pading
#define AUDIO_EP_DELAY_UNIT 0x00 // Unused #define AUDIO_EP_LOCK_DELAY 0x0000 // Unused
You mean in the class specific endpoint descriptor for the audio streaming endpoint? Actually I added it there (bmAttributes = 0x01), but this stops alsa from detecting the device at all. Attaches is the new lsusb out.
Correcting myself. It detects the card, but playback is not possible anymore:
LC_ALL=en speaker-test -Dusb -c 2 -t sine -f 1000
speaker-test 1.0.23
Playback device is usb Stream parameters are 48000Hz, S16_LE, 2 channels Sine wave rate is 1000.0000Hz Rate set to 48000Hz (requested 48000Hz) Buffer size range from 96 to 262144 Period size range from 48 to 131072 Using max buffer size 262144 Periods = 4 Unable to set hw params for playback: Broken pipe Setting of hwparams failed: Broken pipe
Is this a hint to not-working feedback? (c:
On Fri, 2010-10-15 at 19:19 +0200, Julian Scheel wrote:
Correcting myself. It detects the card, but playback is not possible anymore:
LC_ALL=en speaker-test -Dusb -c 2 -t sine -f 1000
speaker-test 1.0.23
Playback device is usb Stream parameters are 48000Hz, S16_LE, 2 channels Sine wave rate is 1000.0000Hz Rate set to 48000Hz (requested 48000Hz) Buffer size range from 96 to 262144 Period size range from 48 to 131072 Using max buffer size 262144 Periods = 4 Unable to set hw params for playback: Broken pipe Setting of hwparams failed: Broken pipe
Is this a hint to not-working feedback? (c:
You may need to respond to the specific requests for get and set of the sampling rate of the audio stream, once you have the Sample Rate Attribute set. See my sdr-widget code to process these requests:
// assume all other requests are for AUDIO interface
switch (request) { case BR_REQUEST_SET_CUR: audio_set_cur(); return TRUE; // No need to break here !
case BR_REQUEST_SET_MIN: //! Set MIN,MAX and RES not supported case BR_REQUEST_SET_MAX: case BR_REQUEST_SET_RES: return FALSE; // No need to break here !
case BR_REQUEST_GET_CUR: audio_get_cur(); return TRUE; // No need to break here !
case BR_REQUEST_GET_MIN: audio_get_min(); return TRUE; // No need to break here !
case BR_REQUEST_GET_MAX: audio_get_max(); return TRUE; // No need to break here !
case BR_REQUEST_GET_RES: audio_get_res(); return TRUE; // No need to break here !
default: return FALSE; // No need to break here ! }
Am Samstag, 16. Oktober 2010, 03:52:54 schrieb Alex Lee:
On Fri, 2010-10-15 at 19:19 +0200, Julian Scheel wrote:
Correcting myself. It detects the card, but playback is not possible anymore:
LC_ALL=en speaker-test -Dusb -c 2 -t sine -f 1000
speaker-test 1.0.23
Playback device is usb Stream parameters are 48000Hz, S16_LE, 2 channels Sine wave rate is 1000.0000Hz Rate set to 48000Hz (requested 48000Hz) Buffer size range from 96 to 262144 Period size range from 48 to 131072 Using max buffer size 262144 Periods = 4 Unable to set hw params for playback: Broken pipe Setting of hwparams failed: Broken pipe
Is this a hint to not-working feedback? (c:
You may need to respond to the specific requests for get and set of the sampling rate of the audio stream, once you have the Sample Rate Attribute set. See my sdr-widget code to process these requests:
Thanks, I implemented them the way same you did. So for get_min/max/cur I always return 48kHz and set_cur simply does nothing. Now playback in general works again. But still the rate feedback seems to have no impact on the data-rate. Also the frequency value shown in proc-interface is unchanged. When rate feedback works, it would probably be slightly different than 48.000kHz?!
Regards, Julian
On Sat, 2010-10-16 at 12:25 +0200, Julian Scheel wrote:
Thanks, I implemented them the way same you did. So for get_min/max/cur I always return 48kHz and set_cur simply does nothing. Now playback in general works again. But still the rate feedback seems to have no impact on the data-rate. Also the frequency value shown in proc-interface is unchanged. When rate feedback works, it would probably be slightly different than 48.000kHz?!
Hi Julian,
OK, you are getting close :-)
One debug technique we have been using is to do a USB wire dump, using something like wireshark. This way you can see exactly what goes on between the PC host and the device.
The other technique is to build a special debug kernel to have copious debug messages.
You might want to double check on the EP limitations. Is the feedback EP capable of ISO transfer? Are you able to use 4 bytes as the max EP size? Is the EP double buffered (required for ISO transfers)? With the wireshark dump you will be able to see exactly what is transferred as the feedback rate.
Also, the Max EP size of the ISO OUT data EP should only be one sample frame (ie 4 bytes in your case - 16 bits x stereo) bigger than the "correct" frame size, ie 192 bytes ====> 196 bytes.
I looked through your updated USB descriptors and they appear to be correct.
Alex
Hi Alex,
Am Samstag, 16. Oktober 2010, 15:58:40 schrieb Alex Lee:
On Sat, 2010-10-16 at 12:25 +0200, Julian Scheel wrote:
Thanks, I implemented them the way same you did. So for get_min/max/cur I always return 48kHz and set_cur simply does nothing. Now playback in general works again. But still the rate feedback seems to have no impact on the data-rate. Also the frequency value shown in proc-interface is unchanged. When rate feedback works, it would probably be slightly different than 48.000kHz?!
OK, you are getting close :-)
I hope so (c:
One debug technique we have been using is to do a USB wire dump, using something like wireshark. This way you can see exactly what goes on between the PC host and the device.
Yes, using wireshark is a good idea indeed. And it immediately turns out what the problem is. The device sends ISOCHRONOUS out packets on the feedback endpoint (5, respectively 0x85) - but when I try to send 4 byte, the URB length is always 0. If I only send 3 or less bytes the packets look fine. I thought it might be a bug regarding max packet size in the at91lib and raised it to 5, but still only 3 bytes can be send. Any clues what might cause such an error?
The other technique is to build a special debug kernel to have copious debug messages.
You might want to double check on the EP limitations. Is the feedback EP capable of ISO transfer? Are you able to use 4 bytes as the max EP size? Is the EP double buffered (required for ISO transfers)? With the wireshark dump you will be able to see exactly what is transferred as the feedback rate.
Yep, using endpoint 5, which is able to do ISO and has dual bank. It allows up to 512byte packet size.
Also, the Max EP size of the ISO OUT data EP should only be one sample frame (ie 4 bytes in your case - 16 bits x stereo) bigger than the "correct" frame size, ie 192 bytes ====> 196 bytes.
Ok, changed that.
I looked through your updated USB descriptors and they appear to be correct.
Fine, thanks (c:
Regards, Julian
Am Samstag, 16. Oktober 2010, 18:30:31 schrieb Julian Scheel:
Hi Alex,
Am Samstag, 16. Oktober 2010, 15:58:40 schrieb Alex Lee:
On Sat, 2010-10-16 at 12:25 +0200, Julian Scheel wrote:
Thanks, I implemented them the way same you did. So for get_min/max/cur I always return 48kHz and set_cur simply does nothing. Now playback in general works again. But still the rate feedback seems to have no impact on the data-rate. Also the frequency value shown in proc-interface is unchanged. When rate feedback works, it would probably be slightly different than 48.000kHz?!
OK, you are getting close :-)
I hope so (c:
One debug technique we have been using is to do a USB wire dump, using something like wireshark. This way you can see exactly what goes on between the PC host and the device.
Yes, using wireshark is a good idea indeed. And it immediately turns out what the problem is. The device sends ISOCHRONOUS out packets on the feedback endpoint (5, respectively 0x85) - but when I try to send 4 byte, the URB length is always 0. If I only send 3 or less bytes the packets look fine. I thought it might be a bug regarding max packet size in the at91lib and raised it to 5, but still only 3 bytes can be send. Any clues what might cause such an error?
I digged deeper into this. Actually all 4 bytes get written to the UDP_FDR register for endpoint 5 properly. Also the TXPKTRDY flag is cleared and set as it should be. So at the sending part in the firmware everything looks fine. Now the question is, why do the package have a length of 0 then?
I attached two wireshark dumps (filtered on endpoint 0x85). One when sending 3 bytes on the feedback pipe (set max packet size to 3 as well). Another one when sending 4 byte (max packet size set to 4). I also tried sending 4 bytes, when max packet size is 3 - as expected it get's properly split up into 2 packets. First has 3 bytes, second 1 byte. Really odd.
Maybe you have an idea when looking at the dumps?
Anyway, as 3 byte feedback sending works, it might be worth to test the 10.14 patch by Clemens to see if the feedback loop itself is working properly then. Can you point me to that patch? Is it already commited to current head?
Regards, Julian
Am Samstag, 16. Oktober 2010, 20:52:02 schrieb Julian Scheel:
Anyway, as 3 byte feedback sending works, it might be worth to test the 10.14 patch by Clemens to see if the feedback loop itself is working properly then. Can you point me to that patch? Is it already commited to current head?
With the patch applied the feedback setting works perfectly fine! Now I just need to tweak my feedback loop to behave well. But generally asynchronous transmission works as expected now! Thanks a lot for the help! Will probably come back with some more questions (c:
-Julian
On Sun, 2010-10-17 at 12:53 +0200, Julian Scheel wrote:
With the patch applied the feedback setting works perfectly fine! Now I just need to tweak my feedback loop to behave well. But generally asynchronous transmission works as expected now! Thanks a lot for the help!
Hi Julian,
Congrats !!!
I have also been testing Clemens' patch for rate feedback format. It works perfectly with the sdr-widget as well, when I set the feedback format to 16.16 in 4 bytes (which OSX can understand). So now I can have one firmware version that works under Linux and OSX.
I'm now working on rate feedback with UAC2. Clemens thinks the format under UAC2 should be 16.16, samples per uFrame. However, I will have to test with OSX to see whether it is accepting samples per millisec (Frame) or samples per uFrame (125 microsec). Whatever OSX uses I will probably use, as Clemens' patch has automatic format so can take whatever format OSX uses.
Thanks Clemens for the great patch :-) OSX should adopt the same approach :-)
Alex
participants (3)
-
Alex Lee -
Clemens Ladisch -
Julian Scheel