How to do USB audio
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 ... 52
Colin (478) 2433 posts |
Jim. Non of your devices have any controls so they will just pass through. Daves device has a volume, mute controls – its really a device for headphones. |
jim lesurf (2082) 1336 posts |
You missed out the smiley. :-) …although come to think of it, maybe you’ve just explained the ‘clipping’ problem with the TW6040 on the PandaBoard. 8-] Note your point about voume controls. The DACMagic Plus has one, but it us a front-panel knob. Presumably not accessible from the ‘host’ which is probably as it should be! Jim |
Colin (478) 2433 posts |
I’m embarrassed by that one I’m taking it out The magic one only has mute controls oddly you can mute each channel separately |
Colin (478) 2433 posts |
Ok attempt 2 Is the correct way to map 16 bit to 24 bit bit 23 = bit 15 or does it need to be more fancy than that. |
Dave Higton (1515) 3404 posts |
To pad a sample to a longer word length, copy the bits left justified in the new field and pad with any constant pattern in the LS bits. Zero seems logical, but anything will do as long as it’s constant. AAMOI, if you pad 16 bits to anything longer and use a varying pattern, it will be a real challenge to hear the result under any realistic listening conditions – i.e. a volume setting that didn’t blast you to deafness if a full level signal were output. |
Colin (478) 2433 posts |
So the number doesn’t represent a value between 0 and 1? I envisaged a 16bit value of 1 would be a 24bit value 1 and a 16bit value of &FFFF a 24 bit value of &FFFFFF. I think you are saying that 1 = &1xx and &FFFF = &FFFFxx is that right? |
Dave Higton (1515) 3404 posts |
I think it may be better if you consider everything as a fraction of full scale. 0×0001 in 16 bit is 1/32768 of full scale. 1/32768 of full scale in 24 bits is 0×000100. (Let’s not get sidetracked by the difference between 1/32768 and 1/32767. It really isn’t significant.) |
Jeffrey Lee (213) 6046 posts |
Pretty much, yeah. When dealing with standard linear sound samples, you need to treat the data as being a fractional number between -1 and 1. So for signed 16bit samples +32767 = 1 and -32767 = -1. To correctly expand that to 24 bit you’d technically have to multiply by 8388607/32767, but in reality just shifting it left 8 bits will produce an acceptable result as the error won’t be any more than 255/8388607 (about 1/32767). And spreading out the bits in the sample data is most definitely not the way to do it! The same techniques hold true when processing pixels in an image – although a 24bpp image may have 8 bits for each of the red, green and blue channels, giving a range of 0-255, you actually need to treat it as a range from 0-1 when converting between different formats. |
jim lesurf (2082) 1336 posts |
I’d echo that. In practice the DACs I use and have been talking about all accept the format which I specify in ALSA (Linux) setups as format S24_3LE In effect, when playing a file or stream with 16bit samples the effect is that the sample values end up in the ‘top’ 16 bits of the 24. I do sometimes refer to this in ways like “shifting up 8 bits” or “padding the last byte”. But I confess I haven’t checked this kind of description as being correct as I’m not sure it rightly indicates how the top bit continues to indicate the sign as it should. If you “pad” the last bytes I’d much prefer it was with effective zeros. Afraid I can’t recall if that means “zeros for +ve values” and “ones for -ve values” or not! If you look at some of the apps that process WAV files on my software page you can see how I tend to hack the values to get them in the correct formats. Jim |
Colin (478) 2433 posts |
in 16 bit 32767 &7fff is the maximum positive value and -32767 &8001 the maximum -ve value Just shifting left 8 gives &7fff00 &800100. Both are less than the maximums &7fffff and &800001 so shifting pads toward silence. Adding &FF to the positive and subtracting &FF from the negative pads toward loudness. It does occur to me that these bits are actually undefined and as such any value is as valid as any other which makes me think that they should be random but I suppose Jim you want toward silence as these values become more significant in quiet passages and quiet passages are better quiet even if it is a false quiet. It does beg the question does a 44100/16bit player of 44100/16bit audio sound better than a 44100/24bit player – interesting. |
jim lesurf (2082) 1336 posts |
Yes. A full explanation of the wherefores risks us requiring a blackboard and a crate of beer to sustain the argument long into the night. :-) However… The critical point is that for audio samples (and other equivalent situations) we have to preserve a uniform quantisation interval (step between adjacent values). The 16-bit range has a change of +/-1 between samples. Quantisation interval = 1. When we scale this up to the ‘24 bit range’ our primary aim is to keep the perfectly uniform interval. Which may mean an apparently strange outcome like one of the ‘extreme’ 16bit values mapping to a 24 bit value that is not at an extreme of the 24bit range. It is more important to have the resulting 16 → 24 values all spaced an interval of 256 (i.e. &100) apart than to ‘fill the range to the brim’. Any other choice will distort the required pattern when converted. For this purpose the least significant bits should be defined to meet this requirement. Jim |
jim lesurf (2082) 1336 posts |
From what I’ve said they should be the same. However theory and practice don’t always agree. BTW The bulk of all audio CD players convert the samples to values of other ‘bit-depths’ and rates. Even the 1st generation Philips players upsampled the rate by x4 and used a 14 bit DAC at x4 rate. Gave essentially the same 16bit resolution. Jim |
nemo (145) 2437 posts |
Nonsense. If you’re extending 16bit signed linear to 24bit signed, do: ORR Rout, Rin, Rin, LSL#17 ; Rin:16-31 are zero beforehand MOV Rout, Rout, ROR#17 MOV Rout, Rout, LSR#7 Or in BASIC: out%=in%AND&7FFF out%=(in%<<8)OR(out%>>7) |
Dave Higton (1515) 3404 posts |
If you’re taking 16 bit samples and feeding them into a 24-bit DAC, you pad the LS 8 bits with any constant value. Whatever the word length is, the value is left justified in the field. You can’t infer anything about the content of the LS 8 bits (of the 24 output bits) from the value of the 16 real bits supplied. If you put in a constant value, the only effect of any particular constant value is a DC shift of no more than 1/32768 of full scale. A DC shift is inaudible. Even noise confined to the 8 LS bits (of 24), given a constant value (i.e. silence) in the MS 16 bits, is going to be inaudible under anything but extreme listening conditions. If you pad the LS 8 bits with something systematically related to the MS 16 bits, it’s a linearity error. |
Dave Higton (1515) 3404 posts |
I’ve just received a USB sound interface I bought from eBay for IIRC £8.75. Still only version 1.00 of the USB Audio Class specification, but it claims to support 8 channels. Quite how it does that with only three 3.5mm output jacks, I don’t know… It also has mic in, line in, S/PDIF in, and S/PDIF out. Actually I think the last two are TOSLink rather than S/PDIF, but S/PDIF seems to have been for years the label regardless of the transmission medium. It may take me a while to work my way through that set of descriptors. There is, unsurprisingly, an alternate setting that supports 2 channels. Sample rates are only 44100Hz and 48000Hz. I feel tempted to look for a cheap optical I/O ADC and/or DAC. |
jim lesurf (2082) 1336 posts |
However it may affect other equipment later in the chain. e.g. some devices look for ‘digital black’ to decide if an input should be muted. Others may have their working upset by dc.
Erm… if you are using the same pattern every time, then it isn’t noise. …and some audiophile situations are pretty extreme. e.g. long portions of classical orchestral music that has not been level compressed can be at quite low levels. This is why 24bit may be very useful. Jim |
Dave Higton (1515) 3404 posts |
A little more news. I’m able to play audio on 4 different USB audio devices I have. I’m more confident now about extracting the information necessary to get devices to work (the above 4 devices each require different settings). It’s only a matter of time (and effort!) now before I can extract the information automatically. One interesting difference is that 3 of the devices have discrete sample rate settings, and must be given the Set Sample Rate command. The iMic’s output sample rate is “continuous” from just under 5 kHz to 48010 Hz, and does not accept a Set Sample Rate command – it treats it as an error. |
jim lesurf (2082) 1336 posts |
That gives me the impression it is ‘adaptive’ and simply tries to supplies samples at whatever rate the ‘host’ can eat. Quite what result you get, heaven knows. May depend critically on the timing of the host feeding it! Alternatively, it may simple sample ‘flat out’ and just discard samples that haven’t been read quickly enough by the host. Source of distortion if so. Jim |
Colin (478) 2433 posts |
An Adaptive source supplies data at a rate requested in a separate isochronous endpoint its the other end of an Asynchronous sink. So If you have an Asynchronous DAC (sink) you need an Adaptive CD player (source) so that the player can supply data at the rate requested by the DAC. If you have an Asynchronous CD player you need an Adaptive DAC to keep up with it. Both schemes should be able to deliver the same quality as the clock is controlled by an external device. The interesting one is using the computer as an Adaptive source, which you do when you play via an Asynchronous DAC. For it to work the computer has to be able to supply data on demand. If the hard disc is on a USB bulk endpoint you have a bulk endpoint supplying an isochronous endpoint. isochronous endpoints always happen once a frame. bulk endpoints may not be given bandwidth on a particular frame – bulk endpoints are low priority. What you really want for an Asynchronous DAC is isochronous access to an Adaptive hard disk. Otherwise you need to ensure USB has enough bandwidth left after it allocates isochronous bandwidth to service the bulk packets. Full speed 96/24bit PCM takes up about 35% bandwidth add a USB CD player and thats another 35% |
Colin (478) 2433 posts |
I’ve just found the descriptors you posted for you iMic. It’s Asynchronous. I think the frequency is selected by alternate number. but I would have expected you to be able to change it via a control request |
Dave Higton (1515) 3404 posts |
There seems to be some confusion around. The continuous sample rate range is for an output (i.e. DAC) – you supply the bytes at whatever (constant) rate you want, the iMic’s output adjusts to that. It refuses to be told what the sample rate is; it works it out from the isochronous data frames. The iMic’s sample rates for input (i.e. ADC) are discrete, it needs to be told the sample rate, and it’s happy to accept the sample rate command. For an input, I don’t know how you could do it any other way. The sampling rate has to be the user’s choice. |
jim lesurf (2082) 1336 posts |
Well “adaptive” can mean almost whatever the individual designer decides! For example, the original DACMagic did what I show on http://www.audiomisc.co.uk/Linux/Sound3/TimeForChange.html Note that Figures 2 and 4 do NOT show the audio waveform. They show the rate of playout. i.e. speed/pitch of what emerges. You can see that the rate of the DACs replay clock regularly hops between two clock rates. They only differ by a few ppm. Each rate is held steady until the next hop. What it is doing is allowing its buffer to slowly fill or empty and switching rate to ‘adapt’ to what the computer host was sending it. So that in the longer term it would ‘keep up OK’. Other DACs may have a smoother lock adjustment so the rate might wander about but roughly settle and follow the source (computer) clock output in the longer term. Cheaper or erm ‘less well designed’ hardware might simply skip or repeat samples to ‘adapt’. Alas, that’s what the Iyonix does. Fortunately for my (remaining dregs of) sanity I’ve forgotten what some of the old Arc podule cards got up to. 8-] Jim |
Colin (478) 2433 posts |
Plenty of scope for confusion when talking about output from a microphone :-) The clock for the adaptive out endpoint comes from the device that feeds it. So the PCM data sample rate and usb clock decides the output rate for data from the computer. Note the mic is Asynchronous so if you sent packets from the mic directly to the speaker it is the mic’s clock which determines the sample rate. This requirement has made me think about adding a c library to the usbdriver. So that modules can be written with lower level access than devicefs allows. Isochronous as it works at the moment couldn’t have worked without altering USBDriver – its not a very scalable solution. With a c library I could have done it in a separate module and not be concerned about breaking code in usbdriver. The clock for Asynchronous endpoints comes from the device so the iMic microphone times the whole process The 7.1 adapter only has discrete frequencies so probably can only accept small variations If you can work out a strategy for iMic I think you’ve cracked it. Does it have headphones or a speaker? |
Colin (478) 2433 posts |
Not really. Without it asynchronous DACs are not possible. Its all to do with who owns the clock. Moving data from a disc to DAC requires 1 clock source driving the whole process. You can’t have an asynchronous disc feeding an an asynchronous DAC because each has its own clock rate and expects devices attached to them to adapt to it. Connect an adaptive disc to an adaptive DAC and neither can decide when to send data. |
Dave Higton (1515) 3404 posts |
Well, I have been able to record from it at multiple sample rates, and I have replayed through it at just the one sample rate so far. Work continues.
It has no transducers; it has two 3.5mm jack sockets, one marked with a loudspeaker icon, one marked with a microphone icon. It outputs at what I presume must be roughly “line level”, and certainly drives my Plantronics headset. |
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 ... 52