Re: [alsa-devel] USB asynchronous mode feedback format
--- 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=88...
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
participants (5)
-
Alex Lee -
Daniel Mack -
Daniel Mack -
Julian Scheel -
lee188＠singnet.com.sg