windows used to force a default resample. that's no longer the case.
it was never the case with linux or alsa. the only time a resample was requested was when the output samplerate != input samplerate.
when I mpd over alsa and leave all options as defaults, I never get my 44.1 stuff upsampled to 48k. I have leds that show the actual output and I'd notice this
I have no idea about how it works on windows, but in Linux, major distributions still resample to 48k in order to be able to play 44.1 content together with 48k - it is done as part of the mixer. On mpd wiki, they do touch on the subject:
Tuning - Music Player Daemon Community Wiki
So if mpd is driving up cpu load, I would make sure the hw_params read what you are expecting.
in all my life using linux, I have never seen any resampling that was not due to:
1) sound card reporting it does NOT support samplerate R
2) a forced manual over-ride setting
3) mixing playback of 2 or more mixed samplerate streams (mixer will have to sort this out)
absent of those 3, I am not convinced that any auto conversion happens. and again, when I look at the leds on my spdif meter, I never see a 48k light come on (ever!) when I play 44.1 music.
I would not worry much about samplerate conversion. its not the big problem on linux that it once was on windows.
1) sound card reporting it does NOT support samplerate R
2) a forced manual over-ride setting
3) mixing playback of 2 or more mixed samplerate streams (mixer will have to sort this out)
absent of those 3, I am not convinced that any auto conversion happens. and again, when I look at the leds on my spdif meter, I never see a 48k light come on (ever!) when I play 44.1 music.
I would not worry much about samplerate conversion. its not the big problem on linux that it once was on windows.
just read the alsa link you posted.
I think you are confused. here's what it says:
Dmix resamples everything to 48khz. (see above url). You can force dmix to resample at 44.1khz, by setting (in /etc/asound.conf or ~/.asoundrc):
that's dmix. dmix is NOT required and is not mandatory for alsa to work.
I don't run dmix and most people don't, either.
more info:
NOTE: For ALSA 1.0.9rc2 and higher you don't need to setup dmix for analogue output. Dmix is enabled by default for soundcards which don't support hardware mixing. You still need to set it up for digital outputs.
Dmix - ALSA wiki
and for us, who use digital outputs, it does not sound like dmix is at all useful or even wanted. the AW certainly announces to linux that it supports all valid samplerates. unless you configure dmix, I don't think it will get in your way in the way you are saying.
I think you are confused. here's what it says:
Dmix resamples everything to 48khz. (see above url). You can force dmix to resample at 44.1khz, by setting (in /etc/asound.conf or ~/.asoundrc):
that's dmix. dmix is NOT required and is not mandatory for alsa to work.
I don't run dmix and most people don't, either.
more info:
NOTE: For ALSA 1.0.9rc2 and higher you don't need to setup dmix for analogue output. Dmix is enabled by default for soundcards which don't support hardware mixing. You still need to set it up for digital outputs.
Dmix - ALSA wiki
and for us, who use digital outputs, it does not sound like dmix is at all useful or even wanted. the AW certainly announces to linux that it supports all valid samplerates. unless you configure dmix, I don't think it will get in your way in the way you are saying.
Hi Alex.
Apologies for the delay in getting around to trying this out.
Have gone through the latest readme file, and followed it to the letter. Firmware flashed OK with no error messages. Uninstalled the original AWSetup drivers. Installed the AWlatestexperimental software instead.
In UAC1 mode, Window7 seems fine. However when switching to UAC2 (manually, on the rear of the DAC unit) the Widget Control now says 'device not found!'. When I switch back to UAC1 manually, all the information is in there and displayed correctly again. Obviously I have done something wrong somewhere, but I do not know what and it's driving me nuts. Again.
Here's a screenshot of my latest settings:
Attachments
Last edited:
The new Widget Control will work in both uac1 and uac2 modes. However, you need to remove the old libusb drivers.
The old widget control uses libusb drivers. The new experimental widget control uses libusbk drivers. You must be having your libusb drivers still installed, thus the libusbk driver cannot connect to the widget in uac2 mode (as the widget has already been captured by the libusb driver).
To completely remove old drivers:
Uninstall Hidden Devices, Drivers, and Services | a Tech-Recipes Tutorial
You need to remove all libusb drivers related to the widget.
This is (one of the) problems with Windows
Alex
The old widget control uses libusb drivers. The new experimental widget control uses libusbk drivers. You must be having your libusb drivers still installed, thus the libusbk driver cannot connect to the widget in uac2 mode (as the widget has already been captured by the libusb driver).
To completely remove old drivers:
Uninstall Hidden Devices, Drivers, and Services | a Tech-Recipes Tutorial
You need to remove all libusb drivers related to the widget.
This is (one of the) problems with Windows
Alex
I did indeed. Just tried it again with same results.
Attachments
Alex, have just seen this stage mentioned in the 'add_to_flip345_bin' folder:
"3 - Download a signed driver Atmel DFU driver from: AVR Freaks Atmel_DFU_64_driver"
This stage isn't mentioned anywhere in the main readme file, and I haven't done it. Could this be the reason? Also I am using Atmel flip 3.4.7...
DAC is working fine with UAC1 and 2, but with a blank Widget Control screen when in UAC2 mode.
- John
"3 - Download a signed driver Atmel DFU driver from: AVR Freaks Atmel_DFU_64_driver"
This stage isn't mentioned anywhere in the main readme file, and I haven't done it. Could this be the reason? Also I am using Atmel flip 3.4.7...
DAC is working fine with UAC1 and 2, but with a blank Widget Control screen when in UAC2 mode.
- John
Last edited:
This is what mine shows. Note that under libusbK USB devices there is one audio interface and two control interfaces (one for uac1 and one for uac2).
If you still cannot get WidgetControl to work under both uac1 and uac2, may be you need to set up a Teamviewer session with Borge or myself to help you to set it up correctly.
If you still cannot get WidgetControl to work under both uac1 and uac2, may be you need to set up a Teamviewer session with Borge or myself to help you to set it up correctly.
An externally hosted image should be here but it was not working when we last tested it.
Note also in my Device Manager display there are "greyed" entries. These entries show the "hidden" device drivers - ie the drivers are installed and ready but the actual devices are not plugged in. So you can see that as my audio-widget is now in uac2 mode, the libusbK audio control device for uac1 mode is greyed. The sound device DG8SAQ-I2C is also greyed (this is the device when the audio-widget in uac1 mode).
In John's device manager screenshot I don't see any greyed entries.
Alex
In John's device manager screenshot I don't see any greyed entries.
Alex
Thanks for all that Alex - still stumped here however. I've just gone and removed all ATMEL and Audio Widget drivers, and removed Widget Control too. Going to start from the ground up again starting with ATMEL Flip drivers first.
Fingers crossed!
For the 'Add_to_flip345_bin' files, should I download the Win7 or the (generic?) windows version from the audio widget download page? As I said a few posts back, the 'win7' version of 'add_to_flip345_bin' is dated Dec2011, and the 'windows' version is dated Jan2012.
Thanks,
- John
Fingers crossed!
For the 'Add_to_flip345_bin' files, should I download the Win7 or the (generic?) windows version from the audio widget download page? As I said a few posts back, the 'win7' version of 'add_to_flip345_bin' is dated Dec2011, and the 'windows' version is dated Jan2012.
Thanks,
- John
Cheers Alex. Didn't bother with any ATMEL stuff this time around (as firmware is already flashed to the latest version from a few days back).
The only thing I installed was AWsetupexperimental. So any drivers installed are via that - I didn't download any USB drivers (I didn't last time for that matter). All working now I am pleased to say! All details appearing in Widget Control in UAC1 or UAC2 modes. Great!
If you look at my screen-grab, you can see it displays libusb0 as well as usbk. As I said above, I didn't install any usb drivers - left it all to AWsetupexperimental, so I assume this is all now correct.
It still doesn't look like your screen - I haven't a clue why. But it's working
Thanks for your help!
- John
The only thing I installed was AWsetupexperimental. So any drivers installed are via that - I didn't download any USB drivers (I didn't last time for that matter). All working now I am pleased to say! All details appearing in Widget Control in UAC1 or UAC2 modes. Great!
If you look at my screen-grab, you can see it displays libusb0 as well as usbk. As I said above, I didn't install any usb drivers - left it all to AWsetupexperimental, so I assume this is all now correct.
It still doesn't look like your screen - I haven't a clue why. But it's working
Thanks for your help!
- John
Attachments
Last edited:
dear borges or Alexlee, you are most qualified to answer my questions about this project of yours so that I should decide if this
asynchronous USB DAC fits my needs;
I am using a TDA1541A DAC in NOS mode (Non Over Samling) so my questions are simple:
will I be able to obtain bitperfect 16 bits at 44,1 khz I2S signal under win7 platform to feed my DAC?
I am asking this because I saw it can handle all the sample rates but they were specified at 24 bits, so my second question is - does this DSP make some kind of processing to the signal like oversampling or upsampling?
my 3-rd and last question is - will I be able to use a custom made 11.2896 clock and slave the "transport" (the PC in this case) with it without using the XO's that are on-board? and if the answer is yes, which pin of the DSP accepts external clock input?
thank you in advance!
asynchronous USB DAC fits my needs;
I am using a TDA1541A DAC in NOS mode (Non Over Samling) so my questions are simple:
will I be able to obtain bitperfect 16 bits at 44,1 khz I2S signal under win7 platform to feed my DAC?
I am asking this because I saw it can handle all the sample rates but they were specified at 24 bits, so my second question is - does this DSP make some kind of processing to the signal like oversampling or upsampling?
my 3-rd and last question is - will I be able to use a custom made 11.2896 clock and slave the "transport" (the PC in this case) with it without using the XO's that are on-board? and if the answer is yes, which pin of the DSP accepts external clock input?
thank you in advance!
To use Audio Widget as Digital input interface.
As I recently found this tread after a bit of google searching...
I have a wish, I want to be able to use the Audio Widget as a part of a DIY portable multichannel (minimum 4 channels) recorder.
I hope to use a RPi or other low power Linux system as a basic for the recorder.
I first found this SourceForge.net: eightsoundsusb using USB audio class 2 for 8 microphone inputs.
The price is not right for me.
I have a need to record 4 microphone signals with exact signal levels, for that I can use my MOTU Traveler MK3 as mic mixer as it can be battery powered.
As this is a very flexible device I can export the digital out signals as either one digital ADAT signal ( 8 channels of 48KHz 24 bits) or 2 SPDIF interfaces each carrying stereo signals between 44.1 up to 192 kHz signals.
I have an idea to use either one of the following:
- OptoRec/Gen
- (if I2S interface) ADAT Receiver Module - www.pcm63.com - All For High Quality Audio DIY
or 2 instances of
- YM3623B Digital Audio Interface Receiver Module - www.pcm63.com - All For High Quality Audio DIY
- DIR9001 SPDIF decoder
The second solution might be a bit more complicated as it needs 2 I2S interfaces ( but maybe cheaper ).
Borge was kind enough to answer my request for more information on how to use the Audio Widget for input with this:
> The parent firmware project (SDR Widget) has support for ADCs, as does the hardware of the USB-I2S module. We just haven't taken the time to write generic ADC support into the audio-widget (on git repository) branch of the firmware yet.
> The project this far is 2-channel only. The I2S interface of the MCU can interface a single SPDIF TX (which is implemented and works on the
AB-1.12/13 prototype bpards). An SPDIF RX could work, but clock control could become interesting. At the moment the USB-I2S module interfaces a DAC board which is also clock matster. The module instructs the DAC to provide either 11.2896 or 12.288MHz clock. With a little tweaking, an SPDIF RX could do the job.
> For two SPDIF RXes, you'll have to give (the forum) some more details on how many audio channels are on each SPDIF and how many are to be recorded at one given time.
> Because we have full control over both MCU firmware and ASIO driver, it is possible to pack bits into a generic stereo audio stream and then unpack them on the PC side. It'd take some programming effort, though.
So my question is, is there any one who has the interest to add to the firmware to enable the Audio Widget to work as a input device?
Sadly I do not have the competence to assist in the programming, but I can at least assist in verifying the functionality of the code
Hoping for development in this direction of the Audio Widget.
Bo-Erik
As I recently found this tread after a bit of google searching...
I have a wish, I want to be able to use the Audio Widget as a part of a DIY portable multichannel (minimum 4 channels) recorder.
I hope to use a RPi or other low power Linux system as a basic for the recorder.
I first found this SourceForge.net: eightsoundsusb using USB audio class 2 for 8 microphone inputs.
The price is not right for me.
I have a need to record 4 microphone signals with exact signal levels, for that I can use my MOTU Traveler MK3 as mic mixer as it can be battery powered.
As this is a very flexible device I can export the digital out signals as either one digital ADAT signal ( 8 channels of 48KHz 24 bits) or 2 SPDIF interfaces each carrying stereo signals between 44.1 up to 192 kHz signals.
I have an idea to use either one of the following:
- OptoRec/Gen
- (if I2S interface) ADAT Receiver Module - www.pcm63.com - All For High Quality Audio DIY
or 2 instances of
- YM3623B Digital Audio Interface Receiver Module - www.pcm63.com - All For High Quality Audio DIY
- DIR9001 SPDIF decoder
The second solution might be a bit more complicated as it needs 2 I2S interfaces ( but maybe cheaper ).
Borge was kind enough to answer my request for more information on how to use the Audio Widget for input with this:
> The parent firmware project (SDR Widget) has support for ADCs, as does the hardware of the USB-I2S module. We just haven't taken the time to write generic ADC support into the audio-widget (on git repository) branch of the firmware yet.
> The project this far is 2-channel only. The I2S interface of the MCU can interface a single SPDIF TX (which is implemented and works on the
AB-1.12/13 prototype bpards). An SPDIF RX could work, but clock control could become interesting. At the moment the USB-I2S module interfaces a DAC board which is also clock matster. The module instructs the DAC to provide either 11.2896 or 12.288MHz clock. With a little tweaking, an SPDIF RX could do the job.
> For two SPDIF RXes, you'll have to give (the forum) some more details on how many audio channels are on each SPDIF and how many are to be recorded at one given time.
> Because we have full control over both MCU firmware and ASIO driver, it is possible to pack bits into a generic stereo audio stream and then unpack them on the PC side. It'd take some programming effort, though.
So my question is, is there any one who has the interest to add to the firmware to enable the Audio Widget to work as a input device?
Sadly I do not have the competence to assist in the programming, but I can at least assist in verifying the functionality of the code
Hoping for development in this direction of the Audio Widget.
Bo-Erik