OK I accept that based on your technical arguments. But in this case it would be helpful to get a DIMA for the hole drilling.
Best Wishes
Pietro
Best Wishes
Pietro
[/quote]
That is nonsense. Front USB ports for USB 2.0 have been around for years on PCs. Even USB 3.0 can be connected off-board (admitted only recently), and that's a lot more speed to pump through the wire.
Good USB connector brackets can be bought in virtually any decent computer shop, it's just a question of using the right pitch header on the board. For USB that should be 0.1". Only if you buy the very cheapest "quality" brackets from China you can't use USB 2.0 speeds.
To use one of these brackets one simply makes a hole in the chassis to put the USB male connector into, and often 2 screw holes to secure the female chassis connector in the case. After that you put the plug on the board and you're done. Most of the brackets have 15-20cm of cable, so this not only prevents alignment errors but also gives you some freedom to mount the board further from the rear (or front) of the chassis.
Try...
running 24/192 audio into a high end system through this:
"That is nonsense. Front USB ports for USB 2.0 have been around for years on PCs"
and compare the results to that of a direct board mounted connector (hopefully on a well designed board). While these convenience ports can be fine for less sensitive (than audio) data, they are not suitable for high performance USB audio.
The fact that even a very good async USB2-SPDIF interface like the Wavelength Audio Wavelink is sensitive to different USB cables illustrates that typical computer data transfer, and audio data transfer function differently in the real world. Go ahead and call my crazy if you like, but I and plenty of others hear these differences quite clearly, and would rather not have the connections from the USB cable to the board compromised in any way.
running 24/192 audio into a high end system through this:
"That is nonsense. Front USB ports for USB 2.0 have been around for years on PCs"
and compare the results to that of a direct board mounted connector (hopefully on a well designed board). While these convenience ports can be fine for less sensitive (than audio) data, they are not suitable for high performance USB audio.
The fact that even a very good async USB2-SPDIF interface like the Wavelength Audio Wavelink is sensitive to different USB cables illustrates that typical computer data transfer, and audio data transfer function differently in the real world. Go ahead and call my crazy if you like, but I and plenty of others hear these differences quite clearly, and would rather not have the connections from the USB cable to the board compromised in any way.
That's something I won't do. Many of the Chinese manufacturers of cables save money on shielding. And many brands simply don't test what quality of cables they've received. So problems in transmissions over USB are certainly possible, esp. if the receiving end doesn't use the resend feature. Which by the way is unclear for this module. Russ, will this module request a resend if there's an error in the data it received?
Is this not an integral part of the usb standard?
Anyway, I would rather miss a few bits in audio than in data files.
The short answer is maybe. I have been toying with using bulk transfer, but this would require some driver tweaking. I am not sure I want to go there or not.
The short answer is that it is something that we can potentially change in firmware/driver combination, but for now I want to stay away from writing drivers for folks.
The initial firmware will be based on the code from XMOS which uses iscochronous transfer. Now isochronous transfer can do error detection via CRC, but offers no built in retry or guarantee of delivery. I will have to see how hard it is to implement those.
The problem arrises that if there are a lot of errors you could get latency that is unacceptable. So it could be that the cure could actually be worse than the disease.
So I will be looking into it, but likely I will implement it as XMOS did.
The short answer is that it is something that we can potentially change in firmware/driver combination, but for now I want to stay away from writing drivers for folks.
The initial firmware will be based on the code from XMOS which uses iscochronous transfer. Now isochronous transfer can do error detection via CRC, but offers no built in retry or guarantee of delivery. I will have to see how hard it is to implement those.
The problem arrises that if there are a lot of errors you could get latency that is unacceptable. So it could be that the cure could actually be worse than the disease.
So I will be looking into it, but likely I will implement it as XMOS did.
Ok looking through some of the low level USB interface code, it look like they already check for CRC errors and then restart. One less thing I need to worry about. Yay! So should this should work great as long as the errors are not so bad as to create a latency beyond which the buffer can cope. I will make the buffer as large as practical.
I practice, I have found it to be very very solid. Sounds superb.
I practice, I have found it to be very very solid. Sounds superb.
It's a standard option, but it's up to the receiving end to act upon what is received. If the receiver sees a CRC error and requests a resend it may run into a buffer underrun: music will stop or start to stutter. For some hardware, simply "ignoring" the errors poses less problems than trying to get the right bits in.
It's really a question of buffer size vs. error rate. If the error rate is 0, one wouldn't need an additional buffer. If the error rate is too high, in the end any buffer will get depleted.
Of course if there is processing room enough, one could use an adaptive algorithm for it: request a resend only if there's enough buffer/time left. That's part of the fun with processors like these: it's all software, so fiddling with it to get it just right is possible.
Wasn't that the evil transfer mode not long ago?
I am assuming that even in an asynchronous set up the actual data transfer from the PC to the USB device is Isync? Only the data is then stored in a buffer and another accurate clock then resyncs/reclocks it then out the data goes? I could be way off on that assumption mind you. But if Asyc, that implies that the clock carrying the data to the USB device and the clock, clocking the data leaving the USB device, aren't the same thing.
Which is why ASRCs don't require a master clock for the incoming data stream, as all it's interested in is the data. It then stores the data in a small buffer, where a new accurate master clock is used to create a new resync'd data stream as well as the rest of the clocks. Or at least that is how I understood it.
The little secret is that async mode is still impemented over isochronous endpoints.
Standard mode has only one pipe going from the PC to the USB audio device which then must recover the clock and follow whatever the PC sends.
Async mode has an isochronous back channel from the Audio device to the PC to adjust the flow. That way you can have the master clock on the USB side.
Cheers
Thomas
Standard mode has only one pipe going from the PC to the USB audio device which then must recover the clock and follow whatever the PC sends.
Async mode has an isochronous back channel from the Audio device to the PC to adjust the flow. That way you can have the master clock on the USB side.
Cheers
Thomas
Quite correct Thomas.
The XMOS code actually looks very good. I won't need to tweak it much if any.
I have also played with bulk transfer, but it is not a standard endpoint for USB audio, and so you would need a custom driver. That not terribly hard to do, just not standard and not something I would want to have to support.
The XMOS code actually looks very good. I won't need to tweak it much if any.
I have also played with bulk transfer, but it is not a standard endpoint for USB audio, and so you would need a custom driver. That not terribly hard to do, just not standard and not something I would want to have to support.
update on availability
Hello TPA guys
can you give a rough estimate on availability of the module?
I got my B2/legato up and running yesterday, but I have no good source to feed it..
I just need to know if to wait for it or buy some interim solution(like the minstreamer or the current TPA usb module)..
thanks a lot for great gear
Eitan
Hello TPA guys
can you give a rough estimate on availability of the module?
I got my B2/legato up and running yesterday, but I have no good source to feed it..
I just need to know if to wait for it or buy some interim solution(like the minstreamer or the current TPA usb module)..
thanks a lot for great gear
Eitan
- Status
- Not open for further replies.