It appears EMU and ARTA use the win registry to exchange information and control of the sample rate. If this is not provided I think the apps will simply ignore it's absence.
If this is the case then we can simply set the ADC sample rate by whatever means and set the sample rate in the apps separately.
Things will be much more reliable with fewer bells and whistles.
Something I discovered while calibrating ARTA with the EMU1212 is ARTA switches the sample rate to 44.1k to do it calibrations. I have no idea why this matters but it is so. ARTA uses 440Hz with it's own generator for calibration. I think this is to minimize spillage into adjacent bins. I guess we will have to right a little manual to go along with the widget pointing out proper calibration procedures.
Cheers,
If this is the case then we can simply set the ADC sample rate by whatever means and set the sample rate in the apps separately.
Things will be much more reliable with fewer bells and whistles.
Something I discovered while calibrating ARTA with the EMU1212 is ARTA switches the sample rate to 44.1k to do it calibrations. I have no idea why this matters but it is so. ARTA uses 440Hz with it's own generator for calibration. I think this is to minimize spillage into adjacent bins. I guess we will have to right a little manual to go along with the widget pointing out proper calibration procedures.
Cheers,
Last edited:
The registry stuff will screw you on Win 7 since it will just engage a sample rate converter.
This has been my experience- I have been using sound cards and PC scopes for around 15 years now. My usually route is to calibrate the system per the software requirements (usually at 48 KHz because all sound cards support 48KHz natively). Many earlier generation sound cards supported other sample rates through internal sample rate conversion making them useless for measurements. Win 7's internal sound engine also does this, converting everything to the selection made for the sound card in the sound>playback>properties>advanced dialog (etc.) For measurements we need bit perfect. I'm still not sure that the EMU driver is not doing digital level control.
In any case once the interface is calibrated I switch to the highest sample rate supported and the deepest bit depth and just leave it. Both of the ADC demo boards I have are jumpered for 192 and I have no need to change them. I really don't see a need for other sample rates in anything I do except for calibration and something I hope no one else here needs to do- test Bluetooth audio devices (they all are compromised).
Left to my own devices at this stage I would make a small ADC board with SPDIF/TOS output hardwired for 192K, possibly with an internal jumper to switch to 48K for calibration, with a clipping light on the front and maybe a gain switch. Battery power is interesting for it, lowest noise, but battery life may make it impractical. I can check the power requirements with the AKM demo board. If 3 9V batteries could get 8 hours it would be a pretty useful device.
If The Audiowidget can take in spdif and either auto sync like a Juli@ or just at preset rates I would be ready to just use it.
The trick enhancement I would like is a bit scope. 24 LEDs that indicate which bits are moving.
Having more control on sample rate etc. is nice and makes the effort more universal in application but probably would not see much use for measurements. Even the QA400 only offers two sample rates and expects you to use one of them.
There are two reasons to look at this even with a QA400- first to work with other software. The QA400 is not an acoustic device measuring tool. Second is to get past the limits of the existing codec.
This has been my experience- I have been using sound cards and PC scopes for around 15 years now. My usually route is to calibrate the system per the software requirements (usually at 48 KHz because all sound cards support 48KHz natively). Many earlier generation sound cards supported other sample rates through internal sample rate conversion making them useless for measurements. Win 7's internal sound engine also does this, converting everything to the selection made for the sound card in the sound>playback>properties>advanced dialog (etc.) For measurements we need bit perfect. I'm still not sure that the EMU driver is not doing digital level control.
In any case once the interface is calibrated I switch to the highest sample rate supported and the deepest bit depth and just leave it. Both of the ADC demo boards I have are jumpered for 192 and I have no need to change them. I really don't see a need for other sample rates in anything I do except for calibration and something I hope no one else here needs to do- test Bluetooth audio devices (they all are compromised).
Left to my own devices at this stage I would make a small ADC board with SPDIF/TOS output hardwired for 192K, possibly with an internal jumper to switch to 48K for calibration, with a clipping light on the front and maybe a gain switch. Battery power is interesting for it, lowest noise, but battery life may make it impractical. I can check the power requirements with the AKM demo board. If 3 9V batteries could get 8 hours it would be a pretty useful device.
If The Audiowidget can take in spdif and either auto sync like a Juli@ or just at preset rates I would be ready to just use it.
The trick enhancement I would like is a bit scope. 24 LEDs that indicate which bits are moving.
Having more control on sample rate etc. is nice and makes the effort more universal in application but probably would not see much use for measurements. Even the QA400 only offers two sample rates and expects you to use one of them.
There are two reasons to look at this even with a QA400- first to work with other software. The QA400 is not an acoustic device measuring tool. Second is to get past the limits of the existing codec.
I second this approach. default is 192... switchable to 48Khz or 96Khz- [ via software command, preferred.]
-RNM
Richard-
Software would require a connection to a PC and some software on the PC, just to switch the sample rate. It would also require an isolator and who knows what else.
The bitscope is the most straightforward way to see things like 16 bit/24 bit and which level is going over the link. I do this now with a scope monitoring the output of a digital receiver, sync on L/R clock and look at data. But a row of LED's would be just as useful and less cumbersome to set up. One of the challenges is to see what is coming from the ADC and if its what you expect.
The Juli@ card uses a 4116 to receive spdif and it seems to be able to figure out the sample rate. I'll dig deeper. The Crystal and Wolfson receivers are viable options as well.
My thought of having an on board oscillator for calibration is like the calibration output on a spectrum analyzer. Its for confidence in measurements. Not necessary but nice to have.
Sorry, wrong part. Its the AK4115 we should look at. The link gives details on how to get it to do lots of useful things.
http://www.akm.com/AppsNotes/AK4115_user_manual.pdf
Bitscope..... we dont need to see anything like 16 or 24b.... just do every test at 24/196. Dont care about anything else because there wont be anything else tested.
Over simplified perhaps but just make it simple and fixed for testing thd/harmonics of the dut. If a dut isnt 24/196 capable then it doesnt need testing IMO.
I wouldnt be interested in a dut of 16/44.1 or anything else.
-Richard
Over simplified perhaps but just make it simple and fixed for testing thd/harmonics of the dut. If a dut isnt 24/196 capable then it doesnt need testing IMO.
I wouldnt be interested in a dut of 16/44.1 or anything else.
-Richard
The only reason I've been looking at the multiple sample rate is because I thought that existing software like ARTA requires it. I also though this would be desirable for some users.
I am happy with the two sample rates QA400 provides but I find myself always switching to 192K anyway wondering why the 48K is even there. We do get a narrower RBW with a lower sample rate for the same number of samples. But does this really matter.
I also think it's a waist to have to use another XO just to get below 48K. I am good with two sample rates and if this is too of much of a pain I'm good with just 192K.
I think setting up an auto sync in the Atmel would be the the easy part. it's a micro controller loaded with hardware modules which can do this sort of thing. I'm more concerned with the ASIO driver. ARTA doesn't seem to be able to connect to it as it is.
I assumed the ASIO driver was capable in both directions and readily useable with existing software at lest with the SDR-Widget. Am I wrong about this assumption?
If the the driver needs further development for capture is there someone willing to do this for us or are we on our own?
I am happy with the two sample rates QA400 provides but I find myself always switching to 192K anyway wondering why the 48K is even there. We do get a narrower RBW with a lower sample rate for the same number of samples. But does this really matter.
I also think it's a waist to have to use another XO just to get below 48K. I am good with two sample rates and if this is too of much of a pain I'm good with just 192K.
I think setting up an auto sync in the Atmel would be the the easy part. it's a micro controller loaded with hardware modules which can do this sort of thing. I'm more concerned with the ASIO driver. ARTA doesn't seem to be able to connect to it as it is.
I assumed the ASIO driver was capable in both directions and readily useable with existing software at lest with the SDR-Widget. Am I wrong about this assumption?
If the the driver needs further development for capture is there someone willing to do this for us or are we on our own?
Question: Which PC software would handle the recording? The reason I'm asking is that beyond 24/48 we will not benefit from the built-in USB audio drivers in Windows.
Also: how is the sample rate set? Is the host able to follow anything the device sets up, or will the host decide the sample rate? If the latter is the case, may the device request a sample rate change?
How these two things are handled will influence the design significantly.
Børge
Also: how is the sample rate set? Is the host able to follow anything the device sets up, or will the host decide the sample rate? If the latter is the case, may the device request a sample rate change?
How these two things are handled will influence the design significantly.
Børge
The works every time with Win7 you get up to 24/48 with HW based on the Audio Widget. Based on closed-source USB audio class 1 you get 24/96. That's due to various fundamental bandwidth limitations.
The other alternative is to use an ASIO driver on Win7. For playback this works very well with the Audio Widget. For recording I have no experience.
I have recently initiated the winuac2 project which aims to create an open-source USB Audio Class 2 driver for Windows. That is going to be a lot of work. Any driver heads out there are very, very welcome to join in!
Børge
The other alternative is to use an ASIO driver on Win7. For playback this works very well with the Audio Widget. For recording I have no experience.
I have recently initiated the winuac2 project which aims to create an open-source USB Audio Class 2 driver for Windows. That is going to be a lot of work. Any driver heads out there are very, very welcome to join in!
Børge
usually you must manually set the software to the hardware/system sample rate. And on Win 7 you must manually set the system to match the hardware or sample rate converters wreck everything.
ASIO may be different. I have been using the ASIO driver from EMU and it works with ARTA but I can't access the EMU control interface any more (software bug, after reinstall even).
Typically the PC SPDIF inputs detect the incoming sample rate and lock to it. Some cards have Async src's on each input- not what we want. The PC sound infrastructure is designed to handle "async" input.
ASIO may be different. I have been using the ASIO driver from EMU and it works with ARTA but I can't access the EMU control interface any more (software bug, after reinstall even).
Typically the PC SPDIF inputs detect the incoming sample rate and lock to it. Some cards have Async src's on each input- not what we want. The PC sound infrastructure is designed to handle "async" input.
If the ADC is a fixed 24 bit depth then only the sample rate can change why would we need to monitor bit depth. The sample rate can be extracted from the L/R clock frequency or the bit clock. It just a frequency counter. If the Atmel can receive an SPDIF then its demodulating the biphase and I2S info is available. Set up one of the timer modules and do a compare. It doesn't need to be checked continuously and it can run at the lowest priority. A bit can be set in some user register to represent the sample rate. The firmware can just check the register bit for change.
"My thought of having an on board oscillator for calibration is like the calibration output on a spectrum analyzer. Its for confidence in measurements. Not necessary but nice to have."
Do you mean an offset low level marker for comparison? Is this for the confidence of measurement like what Victor does with his OSC measurements?
It's a great idea but does it have to be on board. We could include this as an AUX mixer at the analog input and specify a curtain cal level.
Hi Borge,
These are good questions.
With sound cards the apps send a request to the driver and the driver handles the hardware control. There's a small app here ASIO that connects to any ASIO driver, displays information about it and runs a through put test.
Most ASIO drivers have there own control panels which can set parameters as well.
The EMU1212 dsp application is protective and won't allow other apps to change the sample rate. If the sample rate is changed by the DSP app it doesn't change in ARTA.
This doesn't seem to bother ARTA but ARTA continues to display the samples at the rate it was last set for. It doesn't seem to matter if the hardware has a fixed sample rate.
We need a full ASIO driver in mono at least or 2 channels to make this work on a Win OS
I think the ASIO for the Audio-Widget is minimal. Is this correct?
I would say no the host can't follow the sample rate because this was not expected by the app author. It's unusual functioning for a sound card.
I would be happy with an ASIO driver that gets a stream going to the application software. If it doesn't cause a crash then less functionality doesn't matter.
Cheers,
Hi Børge,
Please correct me if I'm wrong, but the 24/48 is not a limitation in windows, right?
As far as I know Ayre doesn't need a special driver when using their QA-9. Only for the QB-9, when running 192KHz, but that's another story.
Mogens
Hi Mogens,
The built-in Windows UAC1 driver handles 24/96. But in the AVR32 case there is a hardware limitation which sets this at 24/48.
However in UAC2 we can go to 32/196. This is limited by the 16Mbps serial interface of the AVR32. But it requires a driver. An ASIO driver for playback is in place and works routinely for the Audio Widget.
I don't know how well the ASIO driver works for recording. But without writing a Windows UAC2 driver, there will be no "Found new Microphone" above 24/48 in a system based on the Audio Widget.
Børge
The built-in Windows UAC1 driver handles 24/96. But in the AVR32 case there is a hardware limitation which sets this at 24/48.
However in UAC2 we can go to 32/196. This is limited by the 16Mbps serial interface of the AVR32. But it requires a driver. An ASIO driver for playback is in place and works routinely for the Audio Widget.
I don't know how well the ASIO driver works for recording. But without writing a Windows UAC2 driver, there will be no "Found new Microphone" above 24/48 in a system based on the Audio Widget.
Børge
Hi Børge,
Well, I think I saw a comment in one thread about migrating the Audio Widget to another processor. In case it's not something I have dreamed up, which would that be?
I have looked at two types in the past. The Atmel SAM3UC, as used on the Amanero board which does 24bit@384Khz, and the STM32F4 series. I think the latter even have 2 I2S ports.
Perhaps I could assist or do the porting of the Audio Widget to one of these, as a background project, if there is any interest?
Mogens
Well, I think I saw a comment in one thread about migrating the Audio Widget to another processor. In case it's not something I have dreamed up, which would that be?
I have looked at two types in the past. The Atmel SAM3UC, as used on the Amanero board which does 24bit@384Khz, and the STM32F4 series. I think the latter even have 2 I2S ports.
Perhaps I could assist or do the porting of the Audio Widget to one of these, as a background project, if there is any interest?
Mogens
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.