Re: USB asynchronous mode feedback format

Re: USB asynchronous mode feedback format

[lee188]

--- Julian Scheel <julian@jusst.de> wrote:
 There may also be
> >a limitation in that the Same EP number cannot be used
> >for both IN and OUT.
> 
> Hm, I'm not sure about this. You think I should move the feedback
> pipe into it's own EP?
> I will recheck the At91SAM7 specs later, to see if I can find a note
> on such a limitation.

Hi Julian,

You might like to refer to this thread:

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=printview&t=88432&start=20

As I have found out, it is not necessary to have the same EP number for IN and OUT for rate feedback to work with a Linux or OSX host.  This may be a requirement for Vista/Win7 hosts though.  We are still doing testing.

Alex

Re: USB asynchronous mode feedback format

[Julian Scheel]

Am Donnerstag, 14. Oktober 2010, 10:47:06 schrieb lee188@singnet.com.sg:
> As I have found out, it is not necessary to have the same EP number for IN
> and OUT for rate feedback to work with a Linux or OSX host.  This may be a
> requirement for Vista/Win7 hosts though.  We are still doing testing.

Hi Alex,

thanks a lot! You made my day (c:
Using EP5 for feedback makes it working. So I now get the data out even in 
async mode. Currently I have a problem left that channel assignment jumps here 
and then. Probably a buffering issue...
Also neither a SRC4192  (sample rate converter) nor a PCM1794 (dac) seem to be 
able to understand what I am sending right now... Not sure why. Looking at the 
measurements it really looks like a proper I2S signal.

Seems you implement something quite similiar as I do. How did you design the 
measurement for actual feedback data to provide? Following the suggestion in 
the spec?

Regards,
Julian

Re: USB asynchronous mode feedback format

[Daniel Mack]

On Thu, Oct 14, 2010 at 12:27:38PM +0200, Julian Scheel wrote:
> thanks a lot! You made my day (c:
> Using EP5 for feedback makes it working. So I now get the data out even in 
> async mode. Currently I have a problem left that channel assignment jumps here 
> and then. Probably a buffering issue...
> Also neither a SRC4192  (sample rate converter) nor a PCM1794 (dac) seem to be 
> able to understand what I am sending right now... Not sure why. Looking at the 
> measurements it really looks like a proper I2S signal.

Can you send oscilloscope screenshots? Which data format are you using?


Daniel

Re: USB asynchronous mode feedback format

[Julian Scheel]

[-- Attachment #1: Type: Text/Plain, Size: 1002 bytes --]

Am Donnerstag, 14. Oktober 2010, 12:48:55 schrieb Daniel Mack:
> On Thu, Oct 14, 2010 at 12:27:38PM +0200, Julian Scheel wrote:
> > thanks a lot! You made my day (c:
> > Using EP5 for feedback makes it working. So I now get the data out even
> > in async mode. Currently I have a problem left that channel assignment
> > jumps here and then. Probably a buffering issue...
> > Also neither a SRC4192  (sample rate converter) nor a PCM1794 (dac) seem
> > to be able to understand what I am sending right now... Not sure why.
> > Looking at the measurements it really looks like a proper I2S signal.
> 
> Can you send oscilloscope screenshots? Which data format are you using?

Sure, attached you see a capture while running speaker-test to generate a 1khz 
sine wave on one channel. (Blue: BCLK 1,536MHz, Yellow: LRCLK: 48kHz, Green: 
I2S data)
If you want to see more/other captures just let me know what you need.

Signal is 48kHz 16Bit. As it's I2S it is MSB with 1 BCLK-Cycle delay.

Regards,
Julian

[-- Attachment #2: 1khzsine_i2s.png --]
[-- Type: image/png, Size: 6017 bytes --]

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: USB asynchronous mode feedback format

[Daniel Mack]

On Thu, Oct 14, 2010 at 01:01:52PM +0200, Julian Scheel wrote:
> Am Donnerstag, 14. Oktober 2010, 12:48:55 schrieb Daniel Mack:
> > On Thu, Oct 14, 2010 at 12:27:38PM +0200, Julian Scheel wrote:
> > > thanks a lot! You made my day (c:
> > > Using EP5 for feedback makes it working. So I now get the data out even
> > > in async mode. Currently I have a problem left that channel assignment
> > > jumps here and then. Probably a buffering issue...
> > > Also neither a SRC4192  (sample rate converter) nor a PCM1794 (dac) seem
> > > to be able to understand what I am sending right now... Not sure why.
> > > Looking at the measurements it really looks like a proper I2S signal.
> > 
> > Can you send oscilloscope screenshots? Which data format are you using?
> 
> Sure, attached you see a capture while running speaker-test to generate a 1khz 
> sine wave on one channel. (Blue: BCLK 1,536MHz, Yellow: LRCLK: 48kHz, Green: 
> I2S data)
> If you want to see more/other captures just let me know what you need.

The dump doesn't show whether the LRCLK is symmetrical, iow, whether the
low phase of LRCLK has the same number of BCLK cycles as the high phase.

But if that's the case, the signals do indeed look alright. Maybe you
need the configure the codec to this format?

Daniel

Re: USB asynchronous mode feedback format

[Julian Scheel]

[-- Attachment #1: Type: Text/Plain, Size: 2001 bytes --]

Am Donnerstag, 14. Oktober 2010, 13:16:12 schrieb Daniel Mack:
> On Thu, Oct 14, 2010 at 01:01:52PM +0200, Julian Scheel wrote:
> > Am Donnerstag, 14. Oktober 2010, 12:48:55 schrieb Daniel Mack:
> > > On Thu, Oct 14, 2010 at 12:27:38PM +0200, Julian Scheel wrote:
> > > > thanks a lot! You made my day (c:
> > > > Using EP5 for feedback makes it working. So I now get the data out
> > > > even in async mode. Currently I have a problem left that channel
> > > > assignment jumps here and then. Probably a buffering issue...
> > > > Also neither a SRC4192  (sample rate converter) nor a PCM1794 (dac)
> > > > seem to be able to understand what I am sending right now... Not
> > > > sure why. Looking at the measurements it really looks like a proper
> > > > I2S signal.
> > > 
> > > Can you send oscilloscope screenshots? Which data format are you using?
> > 
> > Sure, attached you see a capture while running speaker-test to generate a
> > 1khz sine wave on one channel. (Blue: BCLK 1,536MHz, Yellow: LRCLK:
> > 48kHz, Green: I2S data)
> > If you want to see more/other captures just let me know what you need.
> 
> The dump doesn't show whether the LRCLK is symmetrical, iow, whether the
> low phase of LRCLK has the same number of BCLK cycles as the high phase.
> 
> But if that's the case, the signals do indeed look alright. Maybe you
> need the configure the codec to this format?

LRCLK is symmetrical. I use the modules from twistedpearaudio 
(http://www.twistedpearaudio.com/digital/metronome.aspx, 
http://www.twistedpearaudio.com/digital/cod.aspx) because this saved me some 
time designing a PCB for now...
They are configured through DIP switches - and I think correctly. For the SRC 
the settings are:
OWL0,1,2: 0, 0, 0 
OFMT0,1: 1, 0
MODE0,1,2: 1, 0, 0
IFMT0,1,2: 1, 0, 0
BYPASS: 0
LGRP: 0

What I am actually wondering about is, that the SRC produces some output even 
when the input is null. Attached is a picture of this case. I did not measure 
the BCLK this time.

Regards,
Julian

[-- Attachment #2: srcout_noinput.png --]
[-- Type: image/png, Size: 5022 bytes --]

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: USB asynchronous mode feedback format

[Julian Scheel]

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 changed my code to do 12.13 format now. Will try to connect it to my MacBook 
later.
 
> 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.

This actually looks like a good approach. Just studying your code.

> Channel inversion is a known issue and u need to sync the channel to the
> LRCK, and resync when the USB stream is stopped and restarted and when
> doing sample rate changes (48 to 96 etc).

So far I only support one fixed sample rate (48 kHz) in the device. Regarding 
the sync I am wondering how to determine the alignment of the data coming from 
USB. Is there some way to be sure that the data frames do start with the left 
channel when reading them from USB?
The output to the I2S is done in bigger chunks through the DMA engine of the 
AT91SAM7 - it might be possible that I loose one packet in some case at this 
place... This would actually cause a inversion on the channels...

> As for i2s for the DAC etc, u need to have the right timing for the various
> clocks.  As Daniel suggested, u need to scope the signals with a dual
> trace scope to see whether u are giving the DAC and other chips the right
> timing.

See my other mail with the attached measurement.

> If u are interested, u can take a look at our open source project
> sdr-widget.  Google for it.

Yep, I just discovered it. Really nice project. Covers even more than I want 
to do. My goal is only to have a 192kHz/24bit USB->I2S brige which can be used 
for high quality audio designs. If I would have seen your project before I 
might not even have started working on this. Well, now it's topic of my 
bachelor thesis, so I really should get this done (c:

Regards,
Julian

Re: USB asynchronous mode feedback format

[Daniel Mack]

On Thu, Oct 14, 2010 at 01:44:23PM +0200, Julian Scheel wrote:
> Am Donnerstag, 14. Oktober 2010, 13:15:45 schrieb Alex:
> > Channel inversion is a known issue and u need to sync the channel to the
> > LRCK, and resync when the USB stream is stopped and restarted and when
> > doing sample rate changes (48 to 96 etc).
> 
> So far I only support one fixed sample rate (48 kHz) in the device. Regarding 
> the sync I am wondering how to determine the alignment of the data coming from 
> USB. Is there some way to be sure that the data frames do start with the left 
> channel when reading them from USB?

Yes, a USB packet always starts at a sample frame boundary. In other
words, after the SOF, the USB stream will start with the first byte of
the first channel. One USB packet must also transport multiple full
audio frames (ie, samples for all channels), and not only fractions
thereof.

> The output to the I2S is done in bigger chunks through the DMA engine of the 
> AT91SAM7 - it might be possible that I loose one packet in some case at this 
> place... This would actually cause a inversion on the channels...

If you lose one entire packet and catch up with the next one, there
shouldn't be any channel inversion, just a data dropout. However I would
add an extra check to assure your internal counters are in sync whenever
a SOF is received.

Daniel

Re: USB asynchronous mode feedback format

[Julian Scheel]

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

Re: USB asynchronous mode feedback format

[Daniel Mack]

On Thu, Oct 14, 2010 at 01:32:37PM +0200, Julian Scheel wrote:
> Am Donnerstag, 14. Oktober 2010, 13:16:12 schrieb Daniel Mack:
> > The dump doesn't show whether the LRCLK is symmetrical, iow, whether the
> > low phase of LRCLK has the same number of BCLK cycles as the high phase.
> > 
> > But if that's the case, the signals do indeed look alright. Maybe you
> > need the configure the codec to this format?
> 
> LRCLK is symmetrical. I use the modules from twistedpearaudio 
> (http://www.twistedpearaudio.com/digital/metronome.aspx, 
> http://www.twistedpearaudio.com/digital/cod.aspx) because this saved me some 
> time designing a PCB for now...
> They are configured through DIP switches - and I think correctly. For the SRC 
> the settings are:
> OWL0,1,2: 0, 0, 0 
> OFMT0,1: 1, 0
> MODE0,1,2: 1, 0, 0
> IFMT0,1,2: 1, 0, 0
> BYPASS: 0
> LGRP: 0
> 
> What I am actually wondering about is, that the SRC produces some output even 
> when the input is null. Attached is a picture of this case. I did not measure 
> the BCLK this time.

Yes, that looks suspicious, especially because it doesn't only affect
the lower bits. What do you need this sample rate converter for, anyway?
Can't you feed your signals directly to the DAC? FMT0 and FMT1 should
both be set to 0.

Daniel

Re: USB asynchronous mode feedback format

[Julian Scheel]

Am Donnerstag, 14. Oktober 2010, 14:06:41 schrieb Daniel Mack:
> On Thu, Oct 14, 2010 at 01:32:37PM +0200, Julian Scheel wrote:
> > Am Donnerstag, 14. Oktober 2010, 13:16:12 schrieb Daniel Mack:
> > > The dump doesn't show whether the LRCLK is symmetrical, iow, whether
> > > the low phase of LRCLK has the same number of BCLK cycles as the high
> > > phase.
> > > 
> > > But if that's the case, the signals do indeed look alright. Maybe you
> > > need the configure the codec to this format?
> > 
> > LRCLK is symmetrical. I use the modules from twistedpearaudio
> > (http://www.twistedpearaudio.com/digital/metronome.aspx,
> > http://www.twistedpearaudio.com/digital/cod.aspx) because this saved me
> > some time designing a PCB for now...
> > They are configured through DIP switches - and I think correctly. For the
> > SRC the settings are:
> > OWL0,1,2: 0, 0, 0
> > OFMT0,1: 1, 0
> > MODE0,1,2: 1, 0, 0
> > IFMT0,1,2: 1, 0, 0
> > BYPASS: 0
> > LGRP: 0
> > 
> > What I am actually wondering about is, that the SRC produces some output
> > even when the input is null. Attached is a picture of this case. I did
> > not measure the BCLK this time.
> 
> Yes, that looks suspicious, especially because it doesn't only affect
> the lower bits. What do you need this sample rate converter for, anyway?
> Can't you feed your signals directly to the DAC? FMT0 and FMT1 should
> both be set to 0.

You mean OFMT0 and OFMT1? Imho they should be 1,0 for I2S. Or did you refer to 
the DAC? In that case FMT0 and FMT1 both are set to 0.

Julian

Re: USB asynchronous mode feedback format

[Daniel Mack]

On Thu, Oct 14, 2010 at 02:30:43PM +0200, Julian Scheel wrote:
> Am Donnerstag, 14. Oktober 2010, 14:06:41 schrieb Daniel Mack:
> > Yes, that looks suspicious, especially because it doesn't only affect
> > the lower bits. What do you need this sample rate converter for, anyway?
> > Can't you feed your signals directly to the DAC? FMT0 and FMT1 should
> > both be set to 0.
> 
> You mean OFMT0 and OFMT1? Imho they should be 1,0 for I2S. Or did you refer to 
> the DAC? In that case FMT0 and FMT1 both are set to 0.

Jup, I was talking about the DAC.

Daniel

Re: USB asynchronous mode feedback format

[Julian Scheel]

Am Donnerstag, 14. Oktober 2010, 14:33:22 schrieb Daniel Mack:
> On Thu, Oct 14, 2010 at 02:30:43PM +0200, Julian Scheel wrote:
> > Am Donnerstag, 14. Oktober 2010, 14:06:41 schrieb Daniel Mack:
> > > Yes, that looks suspicious, especially because it doesn't only affect
> > > the lower bits. What do you need this sample rate converter for,
> > > anyway? Can't you feed your signals directly to the DAC? FMT0 and FMT1
> > > should both be set to 0.
> > 
> > You mean OFMT0 and OFMT1? Imho they should be 1,0 for I2S. Or did you
> > refer to the DAC? In that case FMT0 and FMT1 both are set to 0.
> 
> Jup, I was talking about the DAC.

I have the SRC in there to be able to always feed that DAC with 192kHz, as it 
performs best in that mode and allows usage of a slow roll-off filter then.
Anyway, I tried to directly feed the DAC module as well, but it does not 
produce any output so far... Not sure what's wrong there.
As the dac is a current output dac, I am not sure whether it really does not 
output any signal, or if the current->voltage conversion does not work.

Julian

Re: USB asynchronous mode feedback format

[Julian Scheel]

Am Donnerstag, 14. Oktober 2010, 13:16:12 schrieb Daniel Mack:
> > Sure, attached you see a capture while running speaker-test to generate a
> > 1khz sine wave on one channel. (Blue: BCLK 1,536MHz, Yellow: LRCLK:
> > 48kHz, Green: I2S data)
> > If you want to see more/other captures just let me know what you need.
> 
> The dump doesn't show whether the LRCLK is symmetrical, iow, whether the
> low phase of LRCLK has the same number of BCLK cycles as the high phase.
> 
> But if that's the case, the signals do indeed look alright. Maybe you
> need the configure the codec to this format?

Hi,

I did a capture of the same signal, but this time not just a short snap, but a 
whole memory dump of the oscilloscope. I did a plot with gnuplot and uploaded 
it here:
http://jusst.de/files/i2s_plot.png

As it's 0,5MB big I didn't want to send it as attachment...

Would you agree that the data (this time blue channel) is delayed too much? 
Looks like it's at least 2 cycles behind the LRCK toggle.
Would it be possible that this is the reason for the DAC not understanding the 
data?

Regards,
Julian

Re: USB asynchronous mode feedback format

[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.

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

Re: USB asynchronous mode feedback format

[Alex Lee]

> Would you agree that the data (this time blue channel) is delayed too much? 
> Looks like it's at least 2 cycles behind the LRCK toggle.
> Would it be possible that this is the reason for the DAC not understanding the 
> data?
> 

Yes it is delayed 2-3 cycles (should be only 1 cycle).  Also, as I
pointed out earlier, data is valid on falling edge of clock.  Should be
rising edge according to i2S.

Alex

Re: USB asynchronous mode feedback format

[Daniel Mack]

On Thu, Oct 14, 2010 at 05:10:01PM +0200, Julian Scheel wrote:
> I did a capture of the same signal, but this time not just a short snap, but a 
> whole memory dump of the oscilloscope. I did a plot with gnuplot and uploaded 
> it here:
> http://jusst.de/files/i2s_plot.png
> 
> As it's 0,5MB big I didn't want to send it as attachment...
> 
> Would you agree that the data (this time blue channel) is delayed too much? 
> Looks like it's at least 2 cycles behind the LRCK toggle.
> Would it be possible that this is the reason for the DAC not understanding the 
> data?

Well, even if it was, you should hear some sound. It might be distorted,
but if you don't get any output, the reason is somewhere else.

Did you check the schematics of your board in comparison to the
reference diagrams in the codec's datasheet? Are there any other things
to be considered maybe?

What about the voltage levels? Are they within the specs? I had a quick
look and it seems that Vdd on the codec has to be within 3.0 .. 3.6V,
while the signals you provide rather seem to be in the range of 5V? The
absolute maximum ratings say that Vdd must not be greater than 4.0V.

Also note that ~11MHz is already in high-speed in a way, so you should
pay attention to data integrity on your bus. I mention that because the
board you sent a link about earlier seems to have terminal blocks for
all signals, so keep the traces short.

I'd suggest to double-check such electicals details first :)

Daniel

Re: USB asynchronous mode feedback format

[Julian Scheel]

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

Re: USB asynchronous mode feedback format

[Julian Scheel]

Am Donnerstag, 14. Oktober 2010, 17:39:13 schrieb Daniel Mack:
> On Thu, Oct 14, 2010 at 05:10:01PM +0200, Julian Scheel wrote:
> > I did a capture of the same signal, but this time not just a short snap,
> > but a whole memory dump of the oscilloscope. I did a plot with gnuplot
> > and uploaded it here:
> > http://jusst.de/files/i2s_plot.png
> > 
> > As it's 0,5MB big I didn't want to send it as attachment...
> > 
> > Would you agree that the data (this time blue channel) is delayed too
> > much? Looks like it's at least 2 cycles behind the LRCK toggle.
> > Would it be possible that this is the reason for the DAC not
> > understanding the data?
> 
> Well, even if it was, you should hear some sound. It might be distorted,
> but if you don't get any output, the reason is somewhere else.

Ok.

> Did you check the schematics of your board in comparison to the
> reference diagrams in the codec's datasheet? Are there any other things
> to be considered maybe?

Couldn't find anything...
Schematic is this: 
http://www.twistedpearaudio.com/docs/digital/cod_schematic.pdf

> What about the voltage levels? Are they within the specs? I had a quick
> look and it seems that Vdd on the codec has to be within 3.0 .. 3.6V,
> while the signals you provide rather seem to be in the range of 5V? The
> absolute maximum ratings say that Vdd must not be greater than 4.0V.

This might indeed be an issue. The clock signals have about 5V level... The 
data coming from the uC still has 4.2V
This might be too much... Stays the question how to lower the voltage properly 
there... Any suggestions?

> Also note that ~11MHz is already in high-speed in a way, so you should
> pay attention to data integrity on your bus. I mention that because the
> board you sent a link about earlier seems to have terminal blocks for
> all signals, so keep the traces short.

Yep, all wires as short as possible and each signal/clock line is drilled 
together with a GND line. The measurements I posted are on the terminal block 
of the DAC module.

> I'd suggest to double-check such electicals details first :)

Not the worst idea (c:

Regards,
Julian

Re: USB asynchronous mode feedback format

[Daniel Mack]

On Thu, Oct 14, 2010 at 05:54:35PM +0200, Julian Scheel wrote:
> Am Donnerstag, 14. Oktober 2010, 17:39:13 schrieb Daniel Mack:
> > What about the voltage levels? Are they within the specs? I had a quick
> > look and it seems that Vdd on the codec has to be within 3.0 .. 3.6V,
> > while the signals you provide rather seem to be in the range of 5V? The
> > absolute maximum ratings say that Vdd must not be greater than 4.0V.
> 
> This might indeed be an issue. The clock signals have about 5V level... The 
> data coming from the uC still has 4.2V
> This might be too much... Stays the question how to lower the voltage properly 
> there... Any suggestions?

This get more and more off-topic for the ALSA community, but ...

For the signals, use a voltage shifter, something like the 74LVC2T45.
For Vdd, if you have to provide that to the board, use a proper
switching power regulator with low ripple, or an LDO, and care well for
blocking.

Also check whether the voltages you applied all the time could have
damaged the chip permanently.

Daniel

Re: USB asynchronous mode feedback format

[Julian Scheel]

Am Donnerstag, 14. Oktober 2010, 18:11:23 schrieb Daniel Mack:
> On Thu, Oct 14, 2010 at 05:54:35PM +0200, Julian Scheel wrote:
> > Am Donnerstag, 14. Oktober 2010, 17:39:13 schrieb Daniel Mack:
> > > What about the voltage levels? Are they within the specs? I had a quick
> > > look and it seems that Vdd on the codec has to be within 3.0 .. 3.6V,
> > > while the signals you provide rather seem to be in the range of 5V? The
> > > absolute maximum ratings say that Vdd must not be greater than 4.0V.
> > 
> > This might indeed be an issue. The clock signals have about 5V level...
> > The data coming from the uC still has 4.2V
> > This might be too much... Stays the question how to lower the voltage
> > properly there... Any suggestions?
> 
> This get more and more off-topic for the ALSA community, but ...

Indeed sorry for that...
 
> For the signals, use a voltage shifter, something like the 74LVC2T45.
> For Vdd, if you have to provide that to the board, use a proper
> switching power regulator with low ripple, or an LDO, and care well for
> blocking.

Even found an easier way, at least for the clock signals. As they are 
generated from a 74HCT4060 right now they are 5V. Replacing it with a 74HC4060 
(or 4040) will allow me to reduce Vcc to 3V, so that the output will match.
Thanks anyway...
 
> Also check whether the voltages you applied all the time could have
> damaged the chip permanently.

Will check it... Have another board in backup for the worst case.

Thanks so far... (c:
Julian

Re: USB asynchronous mode feedback format

[Julian Scheel]

Am Donnerstag, 14. Oktober 2010, 17:39:13 schrieb Daniel Mack:
> Well, even if it was, you should hear some sound. It might be distorted,
> but if you don't get any output, the reason is somewhere else.
> 
> Did you check the schematics of your board in comparison to the
> reference diagrams in the codec's datasheet? Are there any other things
> to be considered maybe?
> 
> What about the voltage levels? Are they within the specs? I had a quick
> look and it seems that Vdd on the codec has to be within 3.0 .. 3.6V,
> while the signals you provide rather seem to be in the range of 5V? The
> absolute maximum ratings say that Vdd must not be greater than 4.0V.

Sorry for one more off-topic mail, but I rechecked it. Digital Input Voltage 
is -0.3V to 6.5V, so my 5V clock voltage should be fine imho. Vdd is 3.0V on 
my board...
Do you maybe have any other thoughts what might be wrong here?

-Julian

Re: USB asynchronous mode feedback format

[Daniel Mack]

On Fri, Oct 15, 2010 at 10:59:32AM +0200, Julian Scheel wrote:
> Am Donnerstag, 14. Oktober 2010, 17:39:13 schrieb Daniel Mack:
> > Well, even if it was, you should hear some sound. It might be distorted,
> > but if you don't get any output, the reason is somewhere else.
> > 
> > Did you check the schematics of your board in comparison to the
> > reference diagrams in the codec's datasheet? Are there any other things
> > to be considered maybe?
> > 
> > What about the voltage levels? Are they within the specs? I had a quick
> > look and it seems that Vdd on the codec has to be within 3.0 .. 3.6V,
> > while the signals you provide rather seem to be in the range of 5V? The
> > absolute maximum ratings say that Vdd must not be greater than 4.0V.
> 
> Sorry for one more off-topic mail, but I rechecked it. Digital Input Voltage 
> is -0.3V to 6.5V, so my 5V clock voltage should be fine imho. Vdd is 3.0V on 
> my board...
> Do you maybe have any other thoughts what might be wrong here?

No, sorry. I think you're doing the right thing by analyzing the digital
stream carefully and checking the electrical components around the
codec. There's usually a ton of things to consider, but it's hard to
tell what to look for without having the same hardware.

Still, let me know what you find :)

Daniel

Re: USB asynchronous mode feedback format

[Julian Scheel]

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

Re: USB asynchronous mode feedback format

[Alex Lee]

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

Re: USB asynchronous mode feedback format

[Julian Scheel]

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

Re: USB asynchronous mode feedback format

[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.

(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

Re: USB asynchronous mode feedback format

[Julian Scheel]

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

Re: USB asynchronous mode feedback format

[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
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

Re: USB asynchronous mode feedback format

[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

Alex		

Re: USB asynchronous mode feedback format

[Julian Scheel]

[-- Attachment #1: Type: Text/Plain, Size: 1091 bytes --]

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

[-- Attachment #2: usbdesc.async --]
[-- Type: text/plain, Size: 5266 bytes --]


Bus 001 Device 012: ID 03eb:6128 Atmel Corp. 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x03eb Atmel Corp.
  idProduct          0x6128 
  bcdDevice            1.00
  iManufacturer           1 Atmel
  iProduct                2 Desktop speaker
  iSerial                 3 0123
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength          119
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass         1 Audio
      bInterfaceSubClass      1 Control Device
      bInterfaceProtocol      0 
      iInterface              0 
      AudioControl Interface Descriptor:
        bLength                 9
        bDescriptorType        36
        bDescriptorSubtype      1 (HEADER)
        bcdADC               1.00
        wTotalLength           40
        bInCollection           1
        baInterfaceNr( 0)       1
      AudioControl Interface Descriptor:
        bLength                12
        bDescriptorType        36
        bDescriptorSubtype      2 (INPUT_TERMINAL)
        bTerminalID             0
        wTerminalType      0x0101 USB Streaming
        bAssocTerminal          1
        bNrChannels             2
        wChannelConfig     0x0003
          Left Front (L)
          Right Front (R)
        iChannelNames           0 
        iTerminal               0 
      AudioControl Interface Descriptor:
        bLength                 9
        bDescriptorType        36
        bDescriptorSubtype      3 (OUTPUT_TERMINAL)
        bTerminalID             1
        wTerminalType      0x0301 Speaker
        bAssocTerminal          0
        bSourceID               2
        iTerminal               0 
      AudioControl Interface Descriptor:
        bLength                10
        bDescriptorType        36
        bDescriptorSubtype      6 (FEATURE_UNIT)
        bUnitID                 2
        bSourceID               0
        bControlSize            1
        bmaControls( 0)      0x01
          Mute Control
        bmaControls( 1)      0x00
        bmaControls( 2)      0x00
        iFeature                0 
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass         1 Audio
      bInterfaceSubClass      2 Streaming
      bInterfaceProtocol      0 
      iInterface              0 
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       1
      bNumEndpoints           2
      bInterfaceClass         1 Audio
      bInterfaceSubClass      2 Streaming
      bInterfaceProtocol      0 
      iInterface              0 
      AudioStreaming Interface Descriptor:
        bLength                 7
        bDescriptorType        36
        bDescriptorSubtype      1 (AS_GENERAL)
        bTerminalLink           0
        bDelay                  0 frames
        wFormatTag              1 PCM
      AudioStreaming Interface Descriptor:
        bLength                11
        bDescriptorType        36
        bDescriptorSubtype      2 (FORMAT_TYPE)
        bFormatType             1 (FORMAT_TYPE_I)
        bNrChannels             2
        bSubframeSize           2
        bBitResolution         16
        bSamFreqType            1 Discrete
        tSamFreq[ 0]        48000
      Endpoint Descriptor:
        bLength                 9
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            5
          Transfer Type            Isochronous
          Synch Type               Asynchronous
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               1
        bRefresh                0
        bSynchAddress         133
        AudioControl Endpoint Descriptor:
          bLength                 7
          bDescriptorType        37
          bDescriptorSubtype      1 (EP_GENERAL)
          bmAttributes         0x01
            Sampling Frequency
          bLockDelayUnits         0 Undefined
          wLockDelay              0 Undefined
      Endpoint Descriptor:
        bLength                 9
        bDescriptorType         5
        bEndpointAddress     0x85  EP 5 IN
        bmAttributes           17
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Feedback
        wMaxPacketSize     0x0004  1x 4 bytes
        bInterval               1
        bRefresh                6
        bSynchAddress           0
Device Status:     0x0000
  (Bus Powered)

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: USB asynchronous mode feedback format

[Julian Scheel]

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:

Re: USB asynchronous mode feedback format

[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:

   //  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 !
	    }

Re: USB asynchronous mode feedback format

[Julian Scheel]

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
> 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.  ;-)

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?

Re: USB asynchronous mode feedback format

[Julian Scheel]

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

Re: USB asynchronous mode feedback format

[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?!

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

Re: USB asynchronous mode feedback format

[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?

> 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

Re: USB asynchronous mode feedback format

[Julian Scheel]

[-- Attachment #1: Type: Text/Plain, Size: 2306 bytes --]

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


[-- Attachment #2: 3byte_feedback.bz2 --]
[-- Type: application/x-bzip, Size: 2086 bytes --]

[-- Attachment #3: 4byte_feedback.bz2 --]
[-- Type: application/x-bzip, Size: 1483 bytes --]

[-- Attachment #4: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: USB asynchronous mode feedback format

[Julian Scheel]

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

Re: USB asynchronous mode feedback format

[Alex Lee]

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

Re: USB asynchronous mode feedback format

[Julian Scheel]

Am Freitag, 15. Oktober 2010, 11:03:21 schrieb Daniel Mack:
> On Fri, Oct 15, 2010 at 10:59:32AM +0200, Julian Scheel wrote:
> > Am Donnerstag, 14. Oktober 2010, 17:39:13 schrieb Daniel Mack:
> > > Well, even if it was, you should hear some sound. It might be
> > > distorted, but if you don't get any output, the reason is somewhere
> > > else.
> > > 
> > > Did you check the schematics of your board in comparison to the
> > > reference diagrams in the codec's datasheet? Are there any other things
> > > to be considered maybe?
> > > 
> > > What about the voltage levels? Are they within the specs? I had a quick
> > > look and it seems that Vdd on the codec has to be within 3.0 .. 3.6V,
> > > while the signals you provide rather seem to be in the range of 5V? The
> > > absolute maximum ratings say that Vdd must not be greater than 4.0V.
> > 
> > Sorry for one more off-topic mail, but I rechecked it. Digital Input
> > Voltage is -0.3V to 6.5V, so my 5V clock voltage should be fine imho.
> > Vdd is 3.0V on my board...
> > Do you maybe have any other thoughts what might be wrong here?
> 
> No, sorry. I think you're doing the right thing by analyzing the digital
> stream carefully and checking the electrical components around the
> codec. There's usually a ton of things to consider, but it's hard to
> tell what to look for without having the same hardware.
> 
> Still, let me know what you find :)

Just figured out what went wrong. The PCM1794A requires the I2S signal to 
contain 24 bit. So when running in 16 bit mode one has to fill up with 8 zero 
bits. Now I doubled the BCLK so that I would be able to send 32 bit to the 
DAC. Still am fighting a bit with the AT91's SSC controller to send only one 
package per L/R frame, but in general I am seeing a proper signal behind the 
DAC now!

Regards,
Julian

Re: USB asynchronous mode feedback format

[lee188]

--- Julian Scheel <julian@jusst.de> wrote:
 There may also be
> >a limitation in that the Same EP number cannot be used
> >for both IN and OUT.
> 
> Hm, I'm not sure about this. You think I should move the feedback
> pipe into it's own EP?
> I will recheck the At91SAM7 specs later, to see if I can find a note
> on such a limitation.

Hi Julian,

You might like to refer to this thread:

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=printview&t=88432&start=20

As I have found out, it is not necessary to have the same EP number for IN and OUT for rate feedback to work with a Linux or OSX host.  This may be a requirement for Vista/Win7 hosts though.  We are still doing testing.

Alex

Re: USB asynchronous mode feedback format

[Alex]

19.13 with the most sig 7 bits not used.

Alex

Sent from my iPhone

On Oct 14, 2010, at 1:57 PM, Julian Scheel <julian@jusst.de> wrote:

> Hi Alex,
> 
> 
> "Alex" <lee188@singnet.com.sg> schrieb:
> 
>> The current alsa rate feedback rate feedback format is
>> 12.13 in 4 bytes.  Clemens has a patch to make the rate
>> feedback format automatic such that it will work with
>> 10.14 16.16 or any other formats.  We are still testing the
>> patch put .  Currently with 12.13 format rate feedback
>> works well.
> 
> How does it come that alsa uses 12.13? I don't see that mentioned in the specs?
> Is it right or left aligned in the 4 bytes?
> 
>> For example, AT91SAM7 has a limitation of EP siE of 64
>> bytes for EP 3 used for ISO transfers.  There may also be
>> a limitation in that the Same EP number cannot be used
>> for both IN and OUT.
> 
> Hm, I'm not sure about this. You think I should move the feedback pipe into it's own EP?
> I will recheck the At91SAM7 specs later, to see if I can find a note on such a limitation.
> 
> Thanks,
> Julian
> 

Re: USB asynchronous mode feedback format

[Julian Scheel]

Hi Alex,


"Alex" <lee188@singnet.com.sg> schrieb:

>The current alsa rate feedback rate feedback format is
>12.13 in 4 bytes.  Clemens has a patch to make the rate
>feedback format automatic such that it will work with
>10.14 16.16 or any other formats.  We are still testing the
>patch put .  Currently with 12.13 format rate feedback
>works well.

How does it come that alsa uses 12.13? I don't see that mentioned in the specs?
Is it right or left aligned in the 4 bytes?

>For example, AT91SAM7 has a limitation of EP siE of 64
>bytes for EP 3 used for ISO transfers.  There may also be
>a limitation in that the Same EP number cannot be used
>for both IN and OUT.

Hm, I'm not sure about this. You think I should move the feedback pipe into it's own EP?
I will recheck the At91SAM7 specs later, to see if I can find a note on such a limitation.

Thanks,
Julian

Re: USB asynchronous mode feedback format

[Alex]

Julian Scheel <julian <at> jusst.de> writes:

> 
> 
> 
Hi Julian,

The current alsa rate feedback rate feedback format is 
12.13 in 4 bytes.  Clemens has a patch to make the rate 
feedback format automatic such that it will work with 
10.14 16.16 or any other formats.  We are still testing the 
patch put .  Currently with 12.13 format rate feedback 
works well.

Mac OSX can work with 10.14 and 16.16.

However, I think your problem lies elsewhere .

For example, AT91SAM7 has a limitation of EP siE of 64 
bytes for EP 3 used for ISO transfers.  There may also be 
a limitation in that the Same EP number cannot be used 
for both IN and OUT.

7
Alex
> 

USB asynchronous mode feedback format

[Julian Scheel]

[-- Attachment #1: Type: Text/Plain, Size: 1129 bytes --]

Hi,

I am currently working on an USB-Audio device based on a AT91SAM7 processor. 
Actually I am currently trying to get the asynchronous mode working, to be 
able to use the AT91SAM7 as I2S transmitter in slave mode, utilizing and 
external clock.
So I added the endpoint descriptors for the Feedback pipe. I attached the 
lsusb output.
Alsa detects the card properly and reports it to be async in the /proc/asound 
interface. Now for a first tested I am trying to report back a constant rate 
through the feedback pipe. The stream is 48kHz with 16Bit.
Reading the USB Audio 1.0 spec I assume in theory for a 48kHz stream I would 
report a rate of 48 samples per frame to the host, compensated by the measured 
drift. As the data should be 10.14 encoded I currently send { 0x0c, 0x00, 0x00 
} on the feedback pipe whenever it is queried, which happens whenever I try to 
play some stream on this device.
But unfortunately the host won't send any data to the device. I am wondering 
what might be wrong and where to check that alsa received the feedback data 
properly?

I would be really thankful for any help!

Regards,
Julian

[-- Attachment #2: usbdesc.async --]
[-- Type: text/plain, Size: 5235 bytes --]


Bus 001 Device 100: ID 03eb:6128 Atmel Corp. 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x03eb Atmel Corp.
  idProduct          0x6128 
  bcdDevice            1.00
  iManufacturer           1 Atmel
  iProduct                2 Desktop speaker
  iSerial                 3 0123
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength          119
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass         1 Audio
      bInterfaceSubClass      1 Control Device
      bInterfaceProtocol      0 
      iInterface              0 
      AudioControl Interface Descriptor:
        bLength                 9
        bDescriptorType        36
        bDescriptorSubtype      1 (HEADER)
        bcdADC               1.00
        wTotalLength           40
        bInCollection           1
        baInterfaceNr( 0)       1
      AudioControl Interface Descriptor:
        bLength                12
        bDescriptorType        36
        bDescriptorSubtype      2 (INPUT_TERMINAL)
        bTerminalID             0
        wTerminalType      0x0101 USB Streaming
        bAssocTerminal          1
        bNrChannels             2
        wChannelConfig     0x0003
          Left Front (L)
          Right Front (R)
        iChannelNames           0 
        iTerminal               0 
      AudioControl Interface Descriptor:
        bLength                 9
        bDescriptorType        36
        bDescriptorSubtype      3 (OUTPUT_TERMINAL)
        bTerminalID             1
        wTerminalType      0x0301 Speaker
        bAssocTerminal          0
        bSourceID               2
        iTerminal               0 
      AudioControl Interface Descriptor:
        bLength                10
        bDescriptorType        36
        bDescriptorSubtype      6 (FEATURE_UNIT)
        bUnitID                 2
        bSourceID               0
        bControlSize            1
        bmaControls( 0)      0x01
          Mute Control
        bmaControls( 1)      0x00
        bmaControls( 2)      0x00
        iFeature                0 
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass         1 Audio
      bInterfaceSubClass      2 Streaming
      bInterfaceProtocol      0 
      iInterface              0 
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       1
      bNumEndpoints           2
      bInterfaceClass         1 Audio
      bInterfaceSubClass      2 Streaming
      bInterfaceProtocol      0 
      iInterface              0 
      AudioStreaming Interface Descriptor:
        bLength                 7
        bDescriptorType        36
        bDescriptorSubtype      1 (AS_GENERAL)
        bTerminalLink           0
        bDelay                  0 frames
        wFormatTag              1 PCM
      AudioStreaming Interface Descriptor:
        bLength                11
        bDescriptorType        36
        bDescriptorSubtype      2 (FORMAT_TYPE)
        bFormatType             1 (FORMAT_TYPE_I)
        bNrChannels             2
        bSubframeSize           2
        bBitResolution         16
        bSamFreqType            1 Discrete
        tSamFreq[ 0]        48000
      Endpoint Descriptor:
        bLength                 9
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            5
          Transfer Type            Isochronous
          Synch Type               Asynchronous
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               1
        bRefresh                0
        bSynchAddress         132
        AudioControl Endpoint Descriptor:
          bLength                 7
          bDescriptorType        37
          bDescriptorSubtype      1 (EP_GENERAL)
          bmAttributes         0x00
          bLockDelayUnits         0 Undefined
          wLockDelay              0 Undefined
      Endpoint Descriptor:
        bLength                 9
        bDescriptorType         5
        bEndpointAddress     0x84  EP 4 IN
        bmAttributes           17
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Feedback
        wMaxPacketSize     0x0003  1x 3 bytes
        bInterval               1
        bRefresh                6
        bSynchAddress           0
Device Status:     0x0000
  (Bus Powered)

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel