I'm up and running with the USB dev_audio_speaker example on MIMXRT1050-EVT. It's possible to recognize the music, but that's about it. It plays at very low volume and for only a limited time.
So before I start hacking at the example I was wondering if:
- Anyone else has a problem with the example, and possible fixes for it
- If NXP provides these examples only as rough starting points or with an ambition of coming close to production status
I'm asking because I'm new to the whole IMX RT space of MCUs, NXP in general, actually. Rough examples are all good and well, I just don't want to waste a lot of time on something which has already been solved or improved elsewhere.
It's so strange. The sound only can be hear for 0.5s and go mute? I think the firmware should be ok, for it works fine at my side. The problem should at hardware or USB driver. There is a rt1050_sai_interrupt_record_playback demo in SDK. It record sound by on board mic and playback by headphone immediately. You can use it to test if there is hardware problem.
If it is ok, you can trace function txCallback() which is in audio_speaker.c. This function send audio data received from USB to SAI.
Hi Jing Pan,
I'm back in the lab and I've been able to give this a proper go. First of all: The audio firmware in dev_audio_speaker_bm is functional on my test computers (Win10/32, Win7/32, OS X). It plays music and test patterns for long periods of time!
So you were completely correct about that! But on my development computer (Win10/64) Windows reports errors and doesn't play music (see below).
Playing from the test computers the volume output is low but functional. To investigate I made a .wav test pattern to check it. (Right channel 0b010010001000010000010000 for 50 samples, 0 for 50 samples. Left constant 0. Only 16 MSBs expected to survive USB interface.) Four things emerge from 'scope plots of this:
- The desired waveform is present, and there is square wave audio in only the right channel
- The interface to the DAC is not I2S, at first inspection it looks like left-justified with R on SAI1_TX_SYNC = 1
- There is some +-1LSB noise at the 16-bit level, possibly dither from the OS, I don't bother for now
- No signs of long-tail FIR filtering (=sample rate conversion)
Now to my Win10/64 machine. "Open sound settings" shows the dev kit as a perfectly good DAC. Device Manager also looks happy, but when I look closer it says under "Events" for the device: "was not migrated due to partial or ambigous match.". I re-built the code with a different USB PID which made Win10 re-discover it. The same error persisted on the development machine, and the new build is still functional on the Mac.
Next, I will investigate this Windows error and reconfigure the dev-kit for I2S communication with another DAC board I will patch in.
I've started working on the sample code, and found multiple ways in which to extend it. To do that efficiently it would help with data flow diagrams between the different functions, flowchart etc. Does this sort of documentation exist?
As for the Windows issue, I have started a dialog with Microsoft on that and will let you know the outcome.
And finally some good news: I set the kit up to produce I2S, the test pattern looks spot-on, and it plays music on an external DAC dev-kit at the expected high volume.
The documents of USB stack is in SDK. When you make and download SDK, you can also download a document package. The USB stack documents are in that package.
There are also some application notes, for example AN4748, AN5385.
When you have problem, you can search in community. You can find many helpful advice here.
You say that audio speaker demo only for a limited time. But I don't see it. I connect EVB to computer, it seems always work.
Yes, the demo work in a fix volume. You can see related code in audio_speaker.c. The function set volume is in USB_DeviceAudioRequest. The code is
if (request->isSetup == 1U)
request->buffer = g_UsbDeviceAudioSpeaker.curVolume;
uint16_t volume = (uint16_t)((uint16_t)g_UsbDeviceAudioSpeaker.curVolume << 8U);
volume |= (uint8_t)(g_UsbDeviceAudioSpeaker.curVolume);
// you can set volume here, for example SetVolume(&codecHandle,kWM8960_ModuleHP,volume);
g_UsbDeviceAudioSpeaker.codecTask |= VOLUME_CHANGE_TASK;
It only read out the volume given by PC, but it doesn't do anything. You can add your volume setting code here.
Thank you Jing for pointing me to the class-specific code!
I'm travelling for a few days. When I'm back in the lab I'll send some generator tones over USB and scope on both the I2S and analog output.
When I first connected it, I had to turn my audio amp all the way up in order to hear anything. I'll let you know how it turns out after I test it a bit more in detail.
My next plan is to implement Audio Class 2 with a few more bells and whistles. Oh, and because NXP keep saying it's impossible, I can't help myself but give DSD a go :-)
All the best,
Hi Jing Pan,
I was able to connect a set of speakers to the RT 1050 kit and upload the dev_audio_speaker_bm project to the test board. It comes up just fine as a USB device.
When I start audio playback, the MIMXRT1050-EVK plays at a reasonable volume for about 0.5s and then the sound goes quiet. I'm able to bring it back to playing music by first stopping the player, switching to the built-in speakers of my laptop, starting the playback and finally toggling back to the USB AUDIO DEMO device. After another 0.5s or less it stops playback. With the equipment here I can't tell if it mutes the analog output or cuts it entirely. When I'm back in the lab I can test further.
While audio mutes, the USB AUDIO DEMO is still listed as present by Windows, and the player program keeps sending audio to it. If I unplug it, the payer stops. So the mute event is distinctly different from a failure of the USB connection.
I have experience on UAC code on the AVR32 platform and look forward to having reliable USB audio on the RT series of MCUs.