This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TM4C123GH6PGE: API_usb_host_audio example Question ( Use DK-TM4C123G)

Part Number: TM4C123GH6PGE
Other Parts Discussed in Thread: TM4C123GH6PM,

Q1> In the figure ③, “pcm xxxx 16bit xxxx. wav ”file cannot be played.    

         Send me a wav file that can be played ?

Q2> I use the audio conversion program of NCH Sotfware Company (www.nch.com.au) Switch Audio Converter.

       Audio source file (a2002011001-e02-16kHz.wav) is changed to pcm 16bit 44.1Khz (uncompressed) file but it does not work.

       Can you tell me what audio conversion program would you recommend?

Q3> I attach a test file (* .wav file).

         Is it convertible to play?

regards.

Jame, Shin

WavFile.zip

  • Hello Jame,

    I will look into this when back in the office. It is a holiday on Monday in the U.S. so it won't be until Tuesday that I can look into this further.

    I don't think we have had to recommend specific wav converters before.

  • Hi Ralph

    Thank you for your reply.

    I will wait for the correct answer.

    Regards 

    Jame.Shin

  • Dear all TI Engineers. !!

    Please advise on my Post.

    Would you please send me a testable Wav file ?

    thanks.

    regards.

    Jame, Shin

  • Hello Jame,

    I suspect that converter isn't matching the format fully, but it's hard to say. I am not an expert with wav files.

    I downloaded a wav file from a free site by searching and tried that on my DK-TM4C129X, and it showed up fine. I am attaching it below for you to test.

    I don't have a DK-TM4C123G on hand so there's a small chance it might not show up well, but I doubt it.

    From your attachment it looked like only a2002011001-e02-16kHz.wav was recognized by my board. Was that the original file? I am not sure what would make it convertible or not.

    As far as sites go, no we don't have a recommendation. The application is just something helpful to get users started, but it's up to each user to handle getting the audio files in the wav format. Our focus is supporting the TM4C device itself.

    Attached: /cfs-file/__key/communityserver-discussions-components-files/908/Heartbeat.wav

  • Hi. Ralph.

    It works for the "Heartbeat.wav" file test you sent.

    Thank you. But I pass so fast that I can't hear one heartbeat.

    So, I checked the "Heartbeat.wav" file attribute. (freewavesample.com)

    I downloaded and tested many wav files from freewavesample.com.

    Questions have arisen.

    Q1> Why is there so much difference in sound quality between PC and EVB via USB Audio Device?

    Q2> Why do I hear very clean sound when I play Wav files through Windows Media Player on my PC?

    Q3> Is it a usb host auduio API problem? Or is it a TM4C problem?

           - The noise is very bad.

    regards.

    Jame, Shin

  • Jame wrote, " I want to hear a continuous and stable heartbeat. !! "

    It is suspected - that the 'heart-owner' - has a (very) similar desire.

    You might check w/various, 'Audio Organizations' - even w/high-end audio magazines - either should be able to 'best direct you.'

    Vendor agents here are 'MCU guys' - part of 'KISS' is knowing, 'How to locate the most suitable source' - which in your case - takes you into the Audio Arena.

    I suspect that, 'Makers of Audio Test Gear' - specifically those accommodating your desired 'WAV' files - would also prove an effective 'WAV file' source.

  • Hello Jame,

    It is a general problem with the EVM you are using. While capable of doing low level audio, the EVM isn't going to produce crystal clear sounds without significant help from external chips like audio codecs. The TM4C device is not an audio device natively and the USB audio example with the wav file player is just to do very basic audio applications for the simplest of sounds. If you want clear and quality audio, you will need more than just the TM4C MCU and that would be true of any generic M4F ARM MCU.

    Regarding the EVM specifically, it doesn't have much of anything to aid it in producing the sound as it is meant to show off general device capability and it is not a 'sound playback EVM' with the required external circuitry to improve audio quality.

    We do have a TI design which is meant to better showcase good audio quality that can be achieved with the TM4C as the host MCU driving everything.

    You can see it here: http://www.ti.com/tool/TIDM-TM4C129POEAUDIO

    For this design, a better audio codec is used to allow for higher quality audio files than .wav, and it has a dedicated audio subsystem to handle the audio playback at higher quality. 

    Here is a description of the audio subsystem: "The audio board primarily has the microphone and a high-SNR, preamplifier stage to capture audio input. The board also has an audio amplifier and a speaker for playing audio. There is a microSD card slot on the bottom of the audio board, which is optional to save audio data, playback, preconfigured audio files, and so on."

    It is that level of additional components that would be needed to improve the audio quality to get closer to the standards you are looking for, though also keep in mind a PC with speakers still has much more processing power and output power for audio than a simple M4F MCU so getting identical quality would be a very aspirational goal.

    Hopefully this information will be helpful for you.

  • Hi Ralph

    Thank you for your reply.

    Usb host audio.c I have a question in the source code

    The source version is TivaWare_C_Series-2.1.4.178

    Q1> The USB pin configuration setting is set in the main () function.

           By the way, the usbsoundinit () function called in main () also sets the USB pin configuration.

           The problem is that I have different USB pin configurations between the two functions.

           Please tell me why the USB pin configuration is different. ?

    Q2> Why are the USB pin configurations different, why do they work?

    Thanks

    Regards

    Jame, Shin

    int
    main(void)
    {
        uint32_t ui32Temp;
        uint32_t ui32Retcode;
    
        //
        // Enable lazy stacking for interrupt handlers.  This allows floating-point
        // instructions to be used within interrupt handlers, but at the expense of
        // extra stack usage.
        //
        ROM_FPULazyStackingEnable();
    
        //
        // Set the system clock to run at 50MHz from the PLL.
        //
        ROM_SysCtlClockSet(SYSCTL_SYSDIV_4 | SYSCTL_USE_PLL | SYSCTL_OSC_MAIN |
                           SYSCTL_XTAL_16MHZ);
    
        //
        // Configure the required pins for USB operation.
        //
        ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOB);
        ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOG);
        ROM_GPIOPinConfigure(GPIO_PG4_USB0EPEN);
        ROM_GPIOPinTypeUSBDigital(GPIO_PORTG_BASE, GPIO_PIN_4);
        ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOL);
        ROM_GPIOPinTypeUSBAnalog(GPIO_PORTL_BASE, GPIO_PIN_6 | GPIO_PIN_7);
        ROM_GPIOPinTypeUSBAnalog(GPIO_PORTB_BASE, GPIO_PIN_0 | GPIO_PIN_1);
    
        //
        // Configure SysTick for a 100Hz interrupt.
        //
        ROM_SysTickPeriodSet(SysCtlClockGet() / TICKS_PER_SECOND);
        ROM_SysTickEnable();
        ROM_SysTickIntEnable();
    
        //
        // Enable Interrupts
        //
        ROM_IntMasterEnable();
    
        //
        // Initialize the display driver.
        //
        CFAL96x64x16Init();
    
        //
        // Initialize the buttons driver.
        //
        ButtonsInit();
    
        //
        // Initialize two offscreen displays and assign the palette.  These
        // buffers are used by the slide menu widget to allow animation effects.
        //
        GrOffScreen4BPPInit(&g_sOffscreenDisplayA, g_pui8OffscreenBufA, 96, 40);
        GrOffScreen4BPPPaletteSet(&g_sOffscreenDisplayA, g_pui32Palette, 0,
                                  NUM_PALETTE_ENTRIES);
        GrOffScreen4BPPInit(&g_sOffscreenDisplayB, g_pui8OffscreenBufB, 96, 40);
        GrOffScreen4BPPPaletteSet(&g_sOffscreenDisplayB, g_pui32Palette, 0,
                                  NUM_PALETTE_ENTRIES);
    
        //
        // Add the compile-time defined widgets to the widget tree.
        //
        WidgetAdd(WIDGET_ROOT, (tWidget *)&g_sHeading);
        WidgetAdd(WIDGET_ROOT, (tWidget *)&g_sStatus);
        WidgetAdd(WIDGET_ROOT, (tWidget *)&g_sFileMenuWidget);
    
        //
        // Initialize the status text.
        //
        strcpy(g_pcStatusText, "No Device");
    
        //
        // Issue the initial paint request to the widgets then immediately call
        // the widget manager to process the paint message.  This ensures that the
        // display is drawn as quickly as possible and saves the delay we would
        // otherwise experience if we processed the paint message after mounting
        // and reading the SD card.
        //
        WidgetPaint(WIDGET_ROOT);
        WidgetMessageQueueProcess();
    
        //
        // Determine whether or not an SD Card is installed.  If not, print a
        // warning and have the user install one and restart.
        //
        ui32Retcode = disk_initialize(0);
    
        if(ui32Retcode != RES_OK)
        {
            g_pcStatusLines[0] = "No SD Card Found";
            g_pcStatusLines[1] = "Please insert";
            g_pcStatusLines[2] = "a card and";
            g_pcStatusLines[3] = "reset the board.";
            ShowStatusScreen(g_pcStatusLines, 4);
            return (1);
        }
        else
        {
            g_pcStatusLines[0] = "SD Card Found";
            ShowStatusScreen(g_pcStatusLines, 1);
    
            //
            // Mount the file system, using logical disk 0.
            //
            f_mount(0, &g_sFatFs);
            if(!FileInit())
            {
                return(1);
            }
        }
    
        //
        // Not playing anything right now.
        //
        g_ui32Flags = 0;
        g_ui32SysTickCount = 0;
        g_ui32LastTick = 0;
        g_ui32CurrentVolume = INITIAL_VOLUME_PERCENT;
    
        //
        // Configure the USB host output.
        //
        USBSoundInit(0, AudioEvent);
    

    This function is called.

    void
    USBSoundInit(uint32_t ui32Flags, tEventCallback pfnCallback)
    {
        //
        // Enable the peripherals used by this example.
        //
        SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);
    
        //
        // Set the USB power pins to be controlled by the USB controller.
        //
        GPIOPinTypeUSBDigital(GPIO_PORTA_BASE, GPIO_PIN_6 | GPIO_PIN_7);
    
        //
        // Enable the uDMA controller and set up the control table base.
        //
        SysCtlPeripheralEnable(SYSCTL_PERIPH_UDMA);
        uDMAEnable();
        uDMAControlBaseSet(g_sDMAControlTable);
    
        //
        // Initialize the USB stack mode to OTG.
        //
        USBStackModeSet(0, eUSBModeOTG, 0);
    
        //
        // Register the host class drivers.
        //
        USBHCDRegisterDrivers(0, g_ppHostClassDrivers, g_ui32NumHostClassDrivers);
    
        //
        // Open an instance of the audio class driver.
        //
        g_psAudioInstance = USBHostAudioOpen(0, AudioCallback);
    
        //
        // Initialize the power configuration. This sets the power enable signal
        // to be active high and does not enable the power fault.
        //
        USBHCDPowerConfigInit(0, USBHCD_VBUS_AUTO_HIGH | USBHCD_VBUS_FILTER);
    
        //
        // Initialize the USB controller for OTG operation with a 2ms polling
        // rate.
        //
        USBOTGModeInit(0, 2000, g_pHCDPool, HCD_MEMORY_SIZE);
    
        //
        // Save the event callback function.
        //
        g_sAudioState.pfnCallbackEvent = pfnCallback;
    }

  • Dear. Ti Engineer

    The previous post may have been insufficient. !!

    USB pin configuration connection schematic in DK-TM4C123G EVB.

    USB0DP   (PL6),   USB0DM   (PL7) ,  USB0ID     (PB0),  USB0VBUS (PB1),  USB0EPEN (PG4)

    1> Correctly configured USB pin configuration in main function source code.

    2> The USBSoundInit () function called inside the main function has been changed as follows.

    USB0DP   (PA6),   USB0DM   (PA7)

    Q1>  What's the reason change to Port A ?

    Thanks

    Regards

    Jame, Shin

  • Jame shin said:

    USB0DP   (PL6),   USB0DM   (PL7) ,  USB0ID     (PB0),  USB0VBUS (PB1),  USB0EPEN (PG4)

    1> Correctly configured USB pin configuration in main function source code.

    2> The USBSoundInit () function called inside the main function has been changed as follows.

    USB0DP   (PA6),   USB0DM   (PA7)

    Q1>  What's the reason change to Port A ?

    I've just 'searched' the TM4C123GH6PM  MCU manual (that's the device used by the '123 LPad) - found 'No Evidence' of pins: 'PL6 or PL7!'    Likely the switch to PA6/PA7 EXTENDS the range of applications!    (maybe)

    If those pins (as named) do 'not' exist - might that prove adequate reason - for the 'suggested change?'

  • Hello cb1,

    The device in question is the TM4C123GH6PGE.

    Jame, I will get back to you in a couple hours on this - looking into it.

  • Hello Ralph,

    Indeed - I noted that (123GH6PGE) in the post's Tag Line.    As noted - FEW here have the '123DK' board - as it has been discontinued.

    If pins PA6/PA7 duplicate PL6/PL7's function - then the '123EK' LPad  (still available)  - may be employed by many for this objective!

  • Hello cb1,

    Ah, sorry, missed the tag while trying to get one more post out before I had to step away! The PA6/PA7 pins do not have that functionality on either device actually. See below for further details.

    Hello Jame,

    From what I can see, this is a mistake with the API coding for that function.

    The code specifically is as follows and has the following comment:

        //
        // Set the USB power pins to be controlled by the USB controller.
        //
        GPIOPinTypeUSBDigital(GPIO_PORTA_BASE, GPIO_PIN_6 | GPIO_PIN_7);

    The mention of power pins and the fact it sets OTG mode to me indicates that it is trying to configure VBUS and USB0ID.

    So in that case, it should be:

        //
        // Set the USB power pins to be controlled by the USB controller.
        //
        GPIOPinTypeUSBAnalog(GPIO_PORTB_BASE, GPIO_PIN_0 | GPIO_PIN_1);

    I am not sure why that configuration was selected but PA6 and PA7 does not have USB functionality for TM4C123x devices from what I can see.

    The reason it worked is because the application is setting the correct pins at the beginning, so the lack of proper initializations is not an issue when UsbSoundInit is called. Though if you were to use PA6/PA7 for other purposes in the application, they would need to be reinitialized afterwards... which is not good.

    I will see about fixing this error with the next TivaWare release.

  • Hello Ralph,

    Q1> Vendor (Ti) first made USB pin configuration in main source code

            Why do you need to set USB pin configuration again?

    Q2> I told the previous post that the audio quality is very bad.

             Isn't the reason for this problem?

    Thanks

    Regards

    Jame, Shin

  • Hello Jame,

    Jame shin said:

    Q1> Vendor (Ti) first made USB pin configuration in main source code

            Why do you need to set USB pin configuration again?

    The logic was that a user may not have configured the power pins beforehand, so the function tried to do that. It did it poorly. If the user did configure them, then it is not needed but it wasn't harm anything. It's a safeguard to make sure the pins are configured no matter what.

    Jame shin said:

    Q2> I told the previous post that the audio quality is very bad.

             Isn't the reason for this problem?

    No, this would not affect that at all.

  • May my small group, 'Agree Completely' w/vendor's Ralph - in his suggestion that (another initialization) proves FAR SAFER (thus BETTER) than 'assuming/hoping' that a 'long past' initialization has remained  'intact & active.'

    So short a code sequence should not impact your desire for 'code brevity.'    

    Note too - when an MCU's Peripheral Operation proves VITAL - often that Peripheral may be:

    • Commanded to RESET
    • Then Re-Initialized

    so that the 'Highest Odds for SUCCESS' are encouraged  (hopefully assured!)