Announcement

Collapse
No announcement yet.

What are the reasons for Sound Buffer blocks to play remains same?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • What are the reasons for Sound Buffer blocks to play remains same?

    I am observing that sound buffer is not emptying. i.e. snd_Playing() is returning some value other than 0, even when no sound is heard. And that value (number of blocks to play) is staying same for a long time. That means that the sound buffer is not emptying. I am looking for what could cause this scenario? We are not using pause function at all.

  • #2
    OTOMH I suspect that the wav file is a bit wrong and has an incorrect value in it's header.

    Can you attache the file here, so we can have a look?
    Mark

    Comment


    • #3
      Note that these files play fine most of the time (ULCD_70DT ). Occasionally only this happens. We are not using while(snd_Playing()), but we are using

      Code:
      if(0 == snd_Playing()) 
      {
        if (trigger is for playing the 1st file == TRUE)
        {
           Then play the 1st file
        }
      }
      
      if(0 == snd_Playing())
      {
        if (trigger is for playing the 2nd file == TRUE)
        {
          Then play the 2nd file
        }
      }
      
      :
      :
      Other tasks, including display change. But display change also check if (0== snd_Playing())

      Note when the buffer is not emptying happens, snd_Playing() always returns 4.
      Attached Files

      Comment


      • #4
        What about this file, the sampling rate of this file is 44,100Hz. Does it cause any problems?

        Audacity is showing the setting as: Mono, 44100Hz, 32-bit float. Does 32-bit float will cause any issue? Previously uploaded files are Mono, 16000Hz, 32-bit float.
        Attached Files

        Comment


        • #5
          Sorry about the delay.

          So I tried various ways of causing those initial two files to 'stop' before their true end. Refer snds.4dg

          I wasn't successful, that included the commented out large image display.

          Not sure where Audacity gets the '32-bit float' from. If you create a dummy Genie project, add a sound object and add the files you get this
          Click image for larger version

Name:	wavdetails.png
Views:	49
Size:	13.0 KB
ID:	74531
          Which shows the details important for Diablo to be able to play the file.

          Maybe there is some other very time intensive 'single line' statement in your code that could be causing the wav buffer to get lost?

          Is your uSD fragmented (do a chkdsk *.* on it from the command prompt)?

          What size sound buffer are you using? (Maybe a larger one will alleviate the issue, although I did try all sizes)
          Mark

          Comment


          • #6
            Hi Mark,

            It seems (after conversion of the above 44,100Hz) that all the files are 16000 Hz, Byte Rate is 32000, Bytes/Sample is 2. Bits per sample is 16, is shown by VisiGene. Still observing the issue. Note that this is not always observed, but intermittently.

            The very strange thing is that, when ever I observe it, it is always showing snd_Playing() return value is 4. Is there any significance to this value?

            Could you expand upon what is a time intensive 'single line' statement and how it affects the wav buffer? The major task, other than playing sound is collecting some data via SPI. (I will also look for there is any other possibilities). Will it impact the behaviour? we are collecting SPI data at every 15ms.

            Ran chkdsk, and found no problem. But it output two messages:
            • name.g01 contains 2 non-contiguous blocks,
            • name.gci contains 2 non-contiguous blocks.

            The current user buffer size I am using is a default size. So it will be 1024 bytes. I will double the size, and run it. And will update the results here.

            Thanks once again.

            Regards.

            Comment


            • #7
              Here is where I have found 32 bit float from audacity:


              File showing that audacity is giving 32-bit Float
              You can see that, After displaying Mono, 44100Hz, it is showing 32-bit Float.

              Comment


              • #8
                An img_Show() for a large image is time intensive, I had that in my test, so that shouldn't be an issue here. for a small image it might be time intensive if the .GCI is fragmented.

                file_LoadImageControl() will also be time intensive, I presume you only do that at the start of your code, but if you do it during regular execution it could be an issue. Fragmentation of both the .GCI and .DAT files will slow this operation down.

                So, generally, any transfer of data from the uSD could be time intensive, or an image type function from a flashbank.

                Can't really see how collecting SPI data could upset things.

                Maybe you could send the code to mark at 4dsystems dot com dot au?

                The 4 is just '4 blocks to go', what is the output from a 'plain' chkdisk on the uSD?
                Mark

                Comment


                • #9
                  Hi Mark,

                  You have written:

                  Refer snds.4dg
                  Where can I refer that file?

                  What are the reasons for .GCI and .G01 to be fragmented?

                  Yes, I am using file_LoadImageControl() only at the start of the code.

                  I was thinking along the lines of interrupts and ISR, and context saving aspect, I was wondering if the SPI interrupt and voice interrupts, affects the processing or not.

                  Another information is that I am using sys_T() to create a non-blocking delay. Another interesting observation:


                  I have increased the buffer size to double, now, when buffer is not emptying is observed, snd_Playing() always returns 8! What are your thoughts on it?

                  Comment


                  • #10
                    I thought I'd attached the file, I'll do it again in this most and check more carefully.

                    Files can become fragmented if the first available space on the uSD card doesn't have enough contiguous space for the file being written. Formatting the card immediately before copying is the easiest way to avoid that.

                    Got the output of the 'plain' chkdsk?

                    ISRs and the like should not affect the sound

                    From the manual snd_Playing() returns the "number of 512 byte blocks to go", so it, sort of, makes sense that if you double the buffer size that number will double.
                    Attached Files
                    Mark

                    Comment


                    • #11
                      I ran the chkdsk, it found no problem.

                      I have done a thorough formatting of the card. And ran chkdsk *.* : Following are the results:

                      All specified files are contigous

                      Comment


                      • #12
                        Sorry, a 'plain' chkdsk... i.e. no *.*, (It produces various stats about the the disks formatting)
                        Mark

                        Comment

                        Working...
                        X