I said it was a crude sketch. Ideally the clocking would be an isolated subsystem with an independent supply and transformer coupled outputs.
The Capture/recording process is fundamentally different from the playback process in a few ways. In playback the file already exists and has sample rate bit depth etc. defined by the file. In recording, the user defines all of those based on a number of aspects, many of which cannot be predicted. These include target use, distribution medium, standalone or part of a different work that needs to be mixed etc. While it may be convenient to select from a computer it can be just as easy to set switches on a box, typical of many premium recording interfaces.
A sound interface with an spdif input will need to sync to the external source, by definition. The internals are usually a receiver chip like this: http://www.asahi-kasei.co.jp/akm/en/product/ak4116/ak4116_f03e.pdf which can detect the incoming sample rate (I would use the crystal version for this, not the decode of the header, which is often wrong). I believe most of the USB audio drivers can handle the sync, its effectively the same as async operation. The chip can report to the interface what the incoming sample rate is. We will need Alex's help (unless you want to figure it out) how to get the info and pass it upstream.
The Capture/recording process is fundamentally different from the playback process in a few ways. In playback the file already exists and has sample rate bit depth etc. defined by the file. In recording, the user defines all of those based on a number of aspects, many of which cannot be predicted. These include target use, distribution medium, standalone or part of a different work that needs to be mixed etc. While it may be convenient to select from a computer it can be just as easy to set switches on a box, typical of many premium recording interfaces.
A sound interface with an spdif input will need to sync to the external source, by definition. The internals are usually a receiver chip like this: http://www.asahi-kasei.co.jp/akm/en/product/ak4116/ak4116_f03e.pdf which can detect the incoming sample rate (I would use the crystal version for this, not the decode of the header, which is often wrong). I believe most of the USB audio drivers can handle the sync, its effectively the same as async operation. The chip can report to the interface what the incoming sample rate is. We will need Alex's help (unless you want to figure it out) how to get the info and pass it upstream.
I already have a PIC set up for control via USB OTG with a crude but workable windows interface. The PIC can control what ever you want. It wouldn't take much to do something that looks fairly decent for a control panel. The PIC can handle the calibration of the ADC as well.
Ah, ok, I think I understand a little more now. You need the controller because you want to be able to control sampling rate and other things from the computer and not via mechanical switches.
That's funny because me being a mechanical engineer, I want all those toggles and rotary switches...
It's fine what ever you come up with. I'm sure it will be great.
It's faster to get expert help. I have to learn all this and that takes time. I,m quite willing to learn it all this. Up to now I really haven't been been interested and I have a bit of catching up to do. I get lost in the terminology a bit. USB audio is different.
From what you describe I believe the TI parts do the same detection. But what part we use doesn't matter as as it does the job.
Just to get things going, I'm going to try to do the mixing in a PIC and see if it can keep up. I think it probably can if that's all it's doing.
That's funny because me being a mechanical engineer, I want all those toggles and rotary switches...
It's fine what ever you come up with. I'm sure it will be great.
Fine we'll do both. I thought you worked in a patent office.
Careful what you ask for. Mechanical switches are great except when there are two pathways to the selection. Mechanical switches indicate their settings directly. if there is a remote pathway then the switch settings can get overridden and you don't know what the settings are. Usually this is dealt with using buttons and indicators, which I think are fine, but the process gets more complex quickly and 2-3 rotary switches became a row of buttons and lights with drivers and more involved mechanicals etc.
The other issue is the power for the PIC (or whatever) and the noise generated by the PIC. There are techniques for reducing/eliminating these issues but they also bring complexity.
What I would like is a simple logic decode from the essential switches: sample rate, clock source, that can control the ADC. There are really only two practical candidates, the TI PCM4222 and the AKM AK5394A I think. The ESS is unknown and the ARDA seems to be a myth. If there are others it would be interesting to know. This would make it possible for a single PCB to support both I believe.
The other issue is the power for the PIC (or whatever) and the noise generated by the PIC. There are techniques for reducing/eliminating these issues but they also bring complexity.
What I would like is a simple logic decode from the essential switches: sample rate, clock source, that can control the ADC. There are really only two practical candidates, the TI PCM4222 and the AKM AK5394A I think. The ESS is unknown and the ARDA seems to be a myth. If there are others it would be interesting to know. This would make it possible for a single PCB to support both I believe.
The Audio/SDR-Widget project already has an MCU and a host software (WidgetControl) which can be expanded to provide both GPIO and computer control. It should be possible to run the control program in low-priority tasks. I don't know the SDR widget user interface, anybody care to elaborate on what's already in place?
Having multiple programmable devices in one box will be a hassle.
Børge
Having multiple programmable devices in one box will be a hassle.
Børge
Since this instrument is for testing audio equipment.... we can make some educated guesses about some settings and make them default. Then what is left to deal with is a minimum if anything at all.
Dont make it very flexible in other words and have all the defaults pre configured (software or hardware switches or both). personally, I dont want to use anything that requires me to know anything about the internal workings...... let the instrument do all the work and no thinking on my part. I only want features like zoom or range changes on freq and levels on the displayed graph/plot. Sample rates et al need to be default or auto-detected.
Later you can add-in options in a drop down menu to change default settings.
Anything done along these lines makes it a useful tool for all....
Thx-RNMarsh
Dont make it very flexible in other words and have all the defaults pre configured (software or hardware switches or both). personally, I dont want to use anything that requires me to know anything about the internal workings...... let the instrument do all the work and no thinking on my part. I only want features like zoom or range changes on freq and levels on the displayed graph/plot. Sample rates et al need to be default or auto-detected.
Later you can add-in options in a drop down menu to change default settings.
Anything done along these lines makes it a useful tool for all....
Thx-RNMarsh
Last edited:
There are only two aspects of the ADC that are hardware- sample rate and input level. The sample rate has a sub set for internal or external clock. The input level scales the input signal to the range of the ADC.
Things like zoom etc are all software and in this case separate from the ADC. An integrated solution like the QA400 would be nice but most of the software people use (ARTA, HPW etc.) are universal and depend on a soundcard as a source that works like a Windows soundcard. Usually there is no provision to control the soundcard at any level. The Praxis approach is to make a separate external box with USB control for gain. Works fine if you control both software and hardware.
Hi Demain,
The PICs are designed to use next to no power. Go to sleep when they're not in use. Even the USB can sleep and wake up on call. Switches would be out but buttons are doable.
I would rather be able to use the Atmel for ererything and I don't see why not. Control is idle until there is a change and then everything needs to reset after a change. It would weird to have more than one USB connected.
But if you think switches would just be quieter then we can do it with switches. There isn't much to change. We can leave space on the board to for either.
I thought we going with the AK5394A.
Cheers,
Last edited:
I can use EMU's little app to change sample rate or I can do this in the ARTA Audio Device setup. This leads me to believe the control is a function provided by the driver or even native to windows. It's no different with any other sound card I've used. Is this a standard? Microsoft played a big part in the development of sound cards. I'll take a look this weekend to see if there's anything on there site. We need to know this before we proceed.
If we change the the sample rate of the ADC via a hardwired switch how does ARTA or other software know the sample rate has changed. We would need to forward that information.
Professional hardware/software functions differently. The QA400 is not a sound card it's completely different. It's proprietary. QuantAsylum just happen to use digital audio hardware to keep the cost down.
Professional hardware/software functions differently. The QA400 is not a sound card it's completely different. It's proprietary. QuantAsylum just happen to use digital audio hardware to keep the cost down.
Demian why don't we approach it as Borges has suggested.
We can have hardware in place for the option of a hardwired switch.
This can be selectable by whatever means. We just need to be able to get that information to the software.
I'm assuming your idea for an on board osc for calibration is for the software calibration is this correct?
We can have hardware in place for the option of a hardwired switch.
This can be selectable by whatever means. We just need to be able to get that information to the software.
I'm assuming your idea for an on board osc for calibration is for the software calibration is this correct?
In my experience, I have to set the sample rate in the software manually to match the ADC.
Yes, there are.
LTC2376-18 - 18-Bit, 250ksps, Low Power SAR ADC with 102dB SNR - Linear Technology
The AKM would be my second choice, though.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.