• State TI Thinks Resolved
  • Locked Locked
  • Replies 30 replies
  • Answers 2 answers
  • Subscribers 103 subscribers
  • Views 610 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

VAR-3P-SOM-AM62: audio glitches after ~45 minutes of playback

inojosh
Prodigy 120 points
Part Number: VAR-3P-SOM-AM62
Other Parts Discussed in Thread: AM625, SK-AM62B-P1

Tool/software:

I am running into an audio issue with our custom hardware, using the AM625 (specifically, the VAR-SOM-AM62 from Variscite). I believe the issue to be at the kernel/driver/chip level, nothing specific to their SOM.
I cannot get the problem to show up on the Variscite EVK. So I believe the issue only shows up due to some specific configuration/combination that exists in our custom image/hardware. Again, I don't think there is a problem with the hardware, only that the hardware reveals some lower level bug/issue.

I have spent several weeks observing this issue and attempting to narrow down the problem.

The Problem
The problem shows up as glitchy audio. It only shows up after playback has been ongoing for some time (after about ~45 minutes). The glitch shows up as 1 of 2 forms:
- Per ALSA period, a few samples are correct and the rest are zeros
- Per ALSA period, a few samples are zero and the rest are correct
So if the ALSA period is 256 samples, the glitch can be seen every 256 samples.

Testing Methodology
Either gstreamer or speaker-test is used to generate a sine wave:

gst-launch-1.0 audiotestsrc freq=440 ! alsasink device=playback1 --verbose

speaker-test -c 2 -r 46512 -t sine -f 440 -D playback1

The audio ultimately hits a DAC, so it is easy enough to observe the result on an o-scope. There are actually multiple DACs, using different formats (one is I2S, the other is TDM). The problem occurs with either. To verify the issue is not occurring somewhere further down the line, rather then coming out of the AM62x, it was easy enough to confirm the MCASP data line also is glitchy, matching what is ultimately seen on the DAC outputs.

A DSP is routing audio between all of these. If the waveform is generated within the DSP, there are no glitches. Just another confirmation that the glitchy audio only happens when originated from the AM62x.

No errors are printed to the console, either from gstreamer or linux (dmesg). There are no reported xruns. Stopping the pipeline and starting it again fixes it immediately.

Unique things about the hardware
The MCASPs (MCASP0 and MCASP2) are connected to an external DSP, rather than traditional codecs. As such, the audio devices are configured as `simple-audio-card` with a patch for allowing a codec of type `snd-soc-dummy`. The ALSA `asound.conf` then has each output/input defined correctly to use the correct samplerate, etc. which is all handled on the DSP side. So, the DSP is the master, providing the BCK and FS clocks. The sample rates are not typical (46512Hz and 186048Hz), but is correctly defined everywhere in the chain.
MCASP0 is TDM16, and MCASP2 is I2S. The problem is exhibited on either one.

As another test, the clocks have been changed to typical audio clocks (48kHz). The problem still appeared.

I have built up a minimal image which starts from a known image (`var-thin-image`), and only adds what is absolutely necessary to test:
 - Patch for `snd-soc-dummy`
- device tree changes for the target hardware
- add some gstreamer packages not included by default (audiotstsrc, alsasink, etc.)
- a minimal `asound.conf` to test a single stereo output of the TDM16 on MCASP0
Then I manually initialize the DAC and DSP (none of my application code is ever actually run). From there, it is just a matter of running that simple gstreamer pipeline and waiting until the output has glitches.

Additionally, I added CONFIG_DYNAMIC_DEBUG, to see if anything useful would be printed out during playback. Nothing useful ended up being printed out after enabling print statements for basically anything related to audio (k3-udma*, sound/core/*, sound/soc/*, etc.)

An additional discovery is that it seems that the glitches do not occur if the sound card is accessed directly.

For the TDM outputs, using dshare or dmix, the glitches show up. They do not seem to occur if accessed directly (e.g. plug to hw:0,0).

Here is scope capture of the audio when it is glitching:

You can see the period between the glitches matches exactly the ALSA period of 256 samples (5.33ms @ 48kHz).

Here is the corresponding MCASP data line

This particular issue has been stalling progress for a while now, so appreciate any insights on this.

  • 0
    TI__Guru* 82035 points

    Hi 

    Thank you for the detailed description on the issue. Have you been in touch with Variscite? Do you have the ability to reproduce the issue on SK-AM62B-P1?  

  • 0 in reply to Mukul Bhatnagar
    Prodigy 120 points

    Mukul,

    I haven't reached out to them with this specific issue, as I believe it is a lower level issue, not specific to their SOM. If I had to guess, I would say it is at the driver level, either davinci-mcasp or dma related, or both. I have seen many other audio related issues in this forum (of which I have tried all the patches) so I wouldn't be too suprised.

    I do not have SK-AM62B-P1, so unfortunately I cannot test it on there. But, it should be easy to test it as it is simply a matter of running a basic sine wave test and leaving it running for a long period of time.

    However, I do have the Variscite Symphony board with the VAR-SOM-AM62.

    In my original post, I said that I wasn't able to replicate the issue there. But, I can amend that now to say the issue does indeed show up there. It just takes a different (longer) amount of time to show up.

    Here is a scope capture of the same type of glitch on the EVK:


    There is some additional glitches that I didn't see in my own hardware. Here it is zoomed in a bit:
    EDIT: this appears to be unrelated noise that was amplified by the cable and scope probe.

  • 0 in reply to inojosh
    TI__Mastermind 20780 points

    Hi,

    Do you have a log to share when the issue occurs? (Probably is there are any underruns/overflows), Can you try and run the same test with smaller period-size and see if the issue occurs?

    Best Regards,

    Suren

  • 0 in reply to Suren Porwar
    Prodigy 120 points

    The logs are not very interesting:

    0:04:59.220894875  1640     0x32bd5580 WARN                    alsa gstalsasink.c:1010:xrun_recovery:<alsasink0> xrun recovery -32: Broken pipe
0:43:01.544439851  1640     0x32bd5580 WARN                    alsa gstalsasink.c:1010:xrun_recovery:<alsasink0> xrun recovery -32: Broken pipe
0:43:01.550710264  1640     0x32bd2800 WARN           audiobasesink gstaudiobasesink.c:1786:gst_audio_base_sink_get_alignment:<alsasink0> Unexpected discontinuity in audio timestamps of +0:00:00.000020833, resyncing 
-- BREAKS -- 
1:11:03.232455286  1640     0x32bd5580 WARN                    alsa gstalsasink.c:1010:xrun_recovery:<alsasink0> xrun recovery -32: Broken pipe
1:31:04.428517986  1640     0x32bd5580 WARN                    alsa gstalsasink.c:1010:xrun_recovery:<alsasink0> xrun recovery -32: Broken pipe
1:33:04.544637428  1640     0x32bd5580 WARN                    alsa gstalsasink.c:1010:xrun_recovery:<alsasink0> xrun recovery -32: Broken pipe
-- FIXED --
    The "--BREAKS--" and "--FIXED--" are my notes as to when the glitch appears, and then later disappears.

    I have tested this with a wide range of period sizes, and they all have the same problem.

    The only difference is the distance between glitches (always 1 period apart).

  • 0 in reply to Suren Porwar
    Prodigy 120 points

    Unfortunately this isn't really possible, as I have to use the Variscite SDK which is always going to be behind the TI SDK.
    That SDK is currently based on TI 9.01.00.08.
    I have tried patching anything related to audio based on things I have seen on this forum, and based on Linux commits between 9.01.00.08 and now. None of them have resolved the glitch issue.

  • 0 in reply to inojosh
    TI__Mastermind 20780 points

    Hi,

    A simple speaker test like below should be able to help reproduce the issue on my end:

    speaker-test -c 2 -r 48000 -t sine -f 440 -D plughw:0,0

    I will try and reproduce this issue first as we have run overnight tests with low period-sizes and haven't see any issues. 

    Best Regards,

    Suren

  • 0 in reply to Suren Porwar
    Prodigy 120 points

    I would suggest running it multiple days, as it was running 40 hours on the EVK when I noticed it.
    Also, it is better to use -c 1 I think, as speaker-test will alternate between the two channels when doing -c 2.
    Also, since it can "unglitch" back to normal, you have to check it periodically.

  • 0 in reply to inojosh
    TI__Mastermind 20780 points

    Hi,

    Since you are on 9.1 SDK release, we would suggest you to migrate to 9.2 or 10.0 released kernel as there have been a lot of fixes related to audio improving latencies and fixing the underruns/overflows issues to improve audio quality.

    Can you verify that the below commit patches are already considered in order to verify the audio functionality on your board:

    Reference: 

    https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/log/?qt=author&q=jai+luthra&h=ti-linux-6.1.y

    Let me know how it goes with all the above patches integrated.

    Best Regards,

    Suren

  • 0 in reply to Suren Porwar
    Prodigy 120 points

    Suren,

    I tried this specific set of patches in your list, and if anything it is making the issue more consistent:

    0:46:36.314685117  1106     0x17555580 WARN                    alsa gstalsasink.c:1010:xrun_recovery:<alsasink0> xrun recovery -32: Broken pipe
1:33:12.560986975  1106     0x17555580 WARN                    alsa gstalsasink.c:1010:xrun_recovery:<alsasink0> xrun recovery -32: Broken pipe
2:19:48.824036149  1106     0x17555580 WARN                    alsa gstalsasink.c:1010:xrun_recovery:<alsasink0> xrun recovery -32: Broken pipe
3:06:25.079554154  1106     0x17555580 WARN                    alsa gstalsasink.c:1010:xrun_recovery:<alsasink0> xrun recovery -32: Broken pipe

    Notice the timestamps for the xruns are very evenly spaced in time.
    The glitch appeared on the first xrun, and continued until the second xrun, which "fixed" it.

    The consistency of it makes me think of an integer overflow type situation.

    Now, this was with accessing the ALSA device via the dshare plugin.

    Accessing the device directly, I have not seen a xrun or glitch (currently running 16 hours).

    It would appear the issue appears while using dshare/dmix to access the output device, but not if the hardware device is accessed directly. Or at the very least, it takes longer for the problem to show up (will have to leave it running to see if this is the case).

  • 0 in reply to Suren Porwar
    Prodigy 120 points

    I just tried this again with a new Variscite SDK based on TI's 09.02.01.10.
    It produced the same result as the previous SDK with the patches applied:

    0:46:36.299947006  1021      0xabe9580 WARN                    alsa gstalsasink.c:1010:xrun_recovery:<alsasink0> xrun recovery -32: Broken pipe
1:33:12.558598771  1021      0xabe9580 WARN                    alsa gstalsasink.c:1010:xrun_recovery:<alsasink0> xrun recovery -32: Broken pipe
2:19:48.813077951  1021      0xabe9580 WARN                    alsa gstalsasink.c:1010:xrun_recovery:<alsasink0> xrun recovery -32: Broken pipe

    Again, extremely specific time periods between xruns, where a the xrun causes the glitch to occur until the next xrun.

    This is what I am running for the test:

    export GST_DEBUG=2
gst-launch-1.0 audiotestsrc freq=440 ! alsasink device=playback_dshare --verbose


    The ALSA config for testing with a dshare device:
    pcm_slave.slaveA {
    pcm "hw:0,0"
    channels 8
    rate 48000
    format S32_LE
}

pcm.playback_dshare {
    type dshare
    ipc_key 1111
    slave slaveA
    bindings [ 0 1 ]
}

  • 0 in reply to inojosh
    TI__Mastermind 20780 points

    Hi,

    Is the direct playback running fine on your test runs instead of dshare?

    Also, can you increase the size CONFIG_SND_HDA_PREALLOC_SIZE from 64 to 2048 and try the experiment to see if the issue resolves.

    Best Regards,

    Suren

  • 0 in reply to Suren Porwar
    Prodigy 120 points

    Changing CONFIG_SND_HDA_PREALLOC_SIZE  did not make a difference.

    From what I have tested, the xrun -> glitch scenario does not occur when the output device is hardware rather than dshare/dmix.

    If you could test what I've shown in my previous post on a TI EVK, that would be great.

  • 0 in reply to Suren Porwar
    Prodigy 110 points

    , , 

    using TI EVK, we have been able to reproduce this behavior with both Yocto BSPs 09.02.01.10 (22 May 2024) and 10.00.07.04 (14 Aug 2024).

    Here the steps

    1. edit /etc/asound.conf as follow

    pcm_slave.slaveA {
        pcm "hw:0,0"
        channels 2
        rate 44100
    }
    pcm.playback_dshare {
        type dshare
        ipc_key 11111
        slave slaveA
        bindings [ 0 1 ]
    }

    2. run the following command

    export GST_DEBUG=2
    gst-launch-1.0 audiotestsrc freq=440 ! alsasink device=playback_dshare --verbose

    This start generating a clean stereo tone at 440 Hz

    3. wait about 7 hours and the tone become suddenly corrupted

    When this happens, the terminal shows xrun notifications, something like this

    root@am62xx-evm:~# uname -a
    Linux am62xx-evm 6.6.32-ti-g6de6e418c80e-dirty #1 SMP PREEMPT Fri Jul 26 14:32:20 UTC 2024 aarch64 GNU/Linux
    root@am62xx-evm:~# export GST_DEBUG=2
    root@am62xx-evm:~# gst-launch-1.0 audiotestsrc freq=440 ! alsasink device=playback_dshare --verbose
    Setting pipeline to PAUSED ...
    Pipeline is PREROLLING ...
    0:00:00.145770469 1570 0xffff84000b70 WARN alsa conf.c:5694:snd_config_expand: alsalib error: Unknown parameters {AES0 0x02 AES1 0x82 AES2 0x00 AES3 0x02}
    0:00:00.145875815 1570 0xffff84000b70 WARN alsa pcm.c:2721:snd_pcm_open_noupdate: alsalib error: Unknown PCM playback_dshare:{AES0 0x02 AES1 0x82 AES2 0x00 AES3 0x02}
    /GstPipeline:pipeline0/GstAudioTestSrc:audiotestsrc0.GstPad:src: caps = audio/x-raw, format=(string)S16LE, layout=(string)interleaved, rate=(int)44100, channels=(int)2, channel-mask=(bitmask)0x0000000000000003
    0:00:00.146676570 1570 0xffff84000b70 WARN alsa pcm_hw.c:1429:snd_pcm_hw_get_chmap: alsalib error: Cannot read Channel Map ctl: No such file or directory
    Redistribute latency...
    /GstPipeline:pipeline0/GstAlsaSink:alsasink0.GstPad:sink: caps = audio/x-raw, format=(string)S16LE, layout=(string)interleaved, rate=(int)44100, channels=(int)2, channel-mask=(bitmask)0x0000000000000003
    Pipeline is PREROLLED ...
    Setting pipeline to PLAYING ...
    Redistribute latency...
    New clock: GstAudioSinkClock
    6:45:48.373691250 1570 0xffff7c00f8e0 WARN alsa gstalsasink.c:1010:xrun_recovery:<alsasink0> xrun recovery -32: Broken pipe
    6:48:38.266189867 1570 0xffff7c00f8e0 WARN alsa gstalsasink.c:1010:xrun_recovery:<alsasink0> xrun recovery -32: Broken pipe

    and the oscilloscope start showing something like this

    with no sound for several milliseconds.

    It looks some kind of DMA problem, but please let us know if you need further detail.

    Thanks

    Best Regards

    Pier

  • 0 in reply to Pierluigi Passaro
    TI__Mastermind 20780 points

    Hi Pier,

    I had given a run on my AM62B-P1 board for more than 10 hours directly without the dshare and  speaker-test ran fine without any issues.

    I have given a run with the above changes in asound.conf . Will keep you posted if we are able to reproduce the issue on our end.

    Best Regards,

    Suren

  • 0 in reply to Suren Porwar
    Prodigy 110 points

    Hi ,

    I confirm that we cannot reproduce the behavior without asound.conf changes.

    Thanks

    Best Regards

    Pier

  • 0 in reply to Pierluigi Passaro
    TI__Mastermind 20780 points

    Hi Pier,

    Pierluigi Passaro said:
    pcm_slave.slaveA {
        pcm "hw:0,0"
        channels 2
        rate 44100
    }
    pcm.playback_dshare {
        type dshare
        ipc_key 11111
        slave slaveA
        bindings [ 0 1 ]
    }

    I just added period_size 64 and buffer_size 8192 in pcm_slave.slaveA and its running fine for more than 12 hours without any issues.  I did see the audio glitch without these two parameters on my end after few hours of running.

    Could you try and experiment on your end with these two parameters added.

    Best Regards,

    Suren

  • 0 in reply to Suren Porwar
    Prodigy 110 points

    Hi ,

    just to avoid misunderstanding, please add the current version of the file asound.conf as you used it for testing.

    Thanks

    Best Regards

    Pier

  • 0 in reply to Pierluigi Passaro
    TI__Mastermind 20780 points

    Hi Pier,

    Its running still without any issues (more than 24 hours now... )

    Here is the asound.conf file contents:

    cat /etc/asound.conf 
# default Arago configuration
pcm_slave.slaveA {
    pcm "hw:0,0"
    channels 2
    period_size 64
    buffer_size 8192
    rate 44100
}
pcm.playback_dshare {
    type dshare
    ipc_key 11111
    slave slaveA
    bindings [ 0 1 ]
}

    Best Regards,

    Suren

  • 0 in reply to Suren Porwar
    Prodigy 120 points

    Suren,

    With all due respect, telling us to change the period and buffer size in order to "fix" the issue is skirting the problem.

    It should work fine with any valid period and buffer size.

    There is clearly an issue here.

    The fact that the underrun happens at exactly the same time every single time is a clear and definite reproducible case. Even if you ignore the fact that the underrun should not happen, an underrun should not result in invalid, glitchy audio for hours at a time, but only a momentary glitch when the underrun occurs.

    Another interesting note is that doing arecord with the suggest period size and buffer size results in ~5.0% CPU usage.

    arecord -r 44100 -f S16_LE -c 2 -D hw:0,0 --period-size=64 --buffer-size=8192 /dev/null

    According to https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/10_00_07_04/exports/docs/devices/AM62X/linux/Linux_Performance_Guide.html

    The CPU usage @ 44.1k is 0.5%, or 10x less. I would be interested to see how this test was performed.

  • 0 in reply to inojosh
    TI__Mastermind 20780 points

    Hi,

    I understand that the xrun should recover and rest of the playback should play fine. I have reached out to our experts on why the DMA loop with McASP is not being cleared properly upon xrun to analyze this further. Currently the team is busy for an upcoming release, so post that they would dedicate the time to root cause the xrun glitchy audio issue.

    I am checking internally on the CPU usage with the validation team. Please allow me a day or two to respond back.

    Best Regards,

    Suren

  • 0 in reply to Suren Porwar
    Prodigy 120 points

    Suren,

    I think it is also important to remember that not only should the xrun not result in this continuous glitchy playback, but the xrun should not happen in the first place. At least in these circumstances - if there was high CPU load, a lot of RT threads, or whatever, sure - but this is not the case here.

    So there is really 2 main issues: that the xrun happens (at a very predictable, repeatable time interval after playback starts) and that the playback is glitchy after the xrun occurs.

  • 0 in reply to inojosh
    TI__Mastermind 20780 points

    I totally agree with you. There should not be any underruns/overflows. Even if it happens, it should recover quickly and produce no artifacts. 

    Will communicate it our team debugging this. 

    Appreciate your patience.

    Best Regards,

    Suren

  • 0 in reply to Suren Porwar
    TI__Mastermind 20780 points

    Hi,

    I tried to record on my setup and the see the CPU % to be 0.7%

    Best Regards,

    Suren

  • 0 in reply to Suren Porwar
    Prodigy 120 points

    Suren,

    Any movement on this issue?
    Considering the time it took to acknowledge the issue, we are losing confidence due to this and other showstopping bugs we are running into, and are looking into switching to another vendors MPU for this and future designs.

  • 0 in reply to inojosh
    TI__Mastermind 20780 points

    Hi,

    Apologies for the delay.

    To reproduce issue faster and check the recovery part from xruns, we set very small period size/buffer size deliberately :

    pcm_slave.slaveA {
    pcm "hw:0,0"
    channels 2
    rate 44100
    period_size 8
    buffer_size 16
}
pcm.playback_dshare {
    type dshare
    ipc_key 11111
    slave slaveA
    bindings [ 0 1 ]
}


    GST_DEBUG=*alsa*:6 GST_DEBUG_FILE="/run/alsa.txt" gst-launch-1.0 audiotestsrc freq=440 ! pulsesink  buffer-time=50 latency-time=50  device=playback_dshare  provide-clock=false sync=false --ver
bose

root@am62xx-evm:~# grep -inr XRUN /run/alsa.txt 
2721:0:00:00.433862972  2155 0xffff94004410 WARN                    alsa gstalsasink.c:1010:xrun_recovery:<alsasink0> xrun recovery -32: Broken pipe
4861:0:00:00.526143094  2155 0xffff94004410 WARN                    alsa gstalsasink.c:1010:xrun_recovery:<alsasink0> xrun recovery -32: Broken pipe
6449:0:00:00.594698518  2155 0xffff94004410 WARN                    alsa gstalsasink.c:1010:xrun_recovery:<alsasink0> xrun recovery -32: Broken pipe
6980:0:00:00.618351079  2155 0xffff94004410 WARN                    alsa gstalsasink.c:1010:xrun_recovery:<alsasink0> xrun recovery -32: Broken pipe
9085:0:00:00.709254596  2155 0xffff94004410 WARN                    alsa gstalsasink.c:1010:xrun_recovery:<alsasink0> xrun recovery -32: Broken pipe
191144:0:00:08.594555230  2155 0xffff94004410 WARN                    alsa gstalsasink.c:1010:xrun_recovery:<alsasink0> xrun recovery -32: Broken pipe
280514:0:00:12.594558238  2155 0xffff94004410 WARN                    alsa gstalsasink.c:1010:xrun_recovery:<alsasink0> xrun recovery -32: Broken pipe
484851:0:00:21.586573984  2155 0xffff94004410 WARN                    alsa gstalsasink.c:1010:xrun_recovery:<alsasink0> xrun recovery -32: Broken pipe
1335712:0:00:58.962530396  2155 0xffff94004410 WARN                    alsa gstalsasink.c:1010:xrun_recovery:<alsasink0> xrun recovery -32: Broken pipe
1487024:0:01:05.618539171  2155 0xffff94004410 WARN                    alsa gstalsasink.c:1010:xrun_recovery:<alsasink0> xrun recovery -32: Broken pipe
1525148:0:01:07.300445396  2155 0xffff94004410 WARN                    alsa gstalsasink.c:1010:xrun_recovery:<alsasink0> xrun recovery -32: Broken pipe
1525182:0:01:07.302713916  2155 0xffff94004410 WARN                    alsa gstalsasink.c:1010:xrun_recovery:<alsasink0> xrun recovery -32: Broken pipe
1790032:0:01:18.930530746  2155 0xffff94004410 WARN                    alsa gstalsasink.c:1010:xrun_recovery:<alsasink0> xrun recovery -32: Broken pipe
1941781:0:01:25.586573613  2155 0xffff94004410 WARN                    alsa gstalsasink.c:1010:xrun_recovery:<alsasink0> xrun recovery -32: Broken pipe

    Did see the xruns being logged but the audio was recovering well after each xrun and no choppiness was observed. So the audio choppiness that you are observing after 7 hours doesn't seem to be related to xrun error recovery. 

    Is there any other way without the dshare plugin, that we are able to reproduce the issue, in order to triage it.

    Best Regards,

    Suren

  • 0 in reply to Suren Porwar
    Prodigy 120 points

    Suren,

    I am not sure what you are asking for. I've provided the info to reproduce the issue, and you have reproduced it.

    It is unfortunate it takes so long for it to occur, but that also should give some hints where to look (it takes a long time and always takes exactly the same amount of time). If I knew a way to make the issue appear more quickly, I would have provided that information.

  • 0 in reply to inojosh
    TI__Mastermind 20780 points

    Hi,

    I apologize for a delay in responding back. The team has been working on root causing this issue and found that there is no proper handshake or communication channel between dmix and gstreamer pipeline. The gstreamer plugin does not have capability to read the the buffer size/period size configured by the dshare plugin.So dmix/dshare plugin is forcing certain period size and buffer size globally and those are not communicated to gstreamer pipeline and gstreamer is assuming the period size/buffer size to be something else.

    So whatever period size/buffer size is set by dmix you need to set those manually to gstreamer as well. For e.g. dmix was setting period size as 5513 and buffer size to 16539 as default.

    So I set those both in asound.conf and gstreamer pipeline and ran it for ~64 hours with below pipeline (also added a queue element for threading) and it ran fine without any issues.

     

    # default Arago configurationpcm_slave.slaveA {
    pcm "hw:0,0"
    channels 2
    rate 44100
    period_size 5513
    buffer_size 16539
    format "S16_LE"
}pcm.playback_dshare {
    type dshare
    ipc_key 11111
    slave slaveA
    bindings [ 0 1 ]}

     GST_DEBUG=alsa:3 GST_DEBUG_FILE="/run/alsa.txt" gst-launch-1.0 audiotestsrc is-live=true freq=440 ! queue ! alsasink device=playback_dshare latency-time=125000 buffer-time=375000 provide-clock=false sync=false --verbose

     With this configuration, it works fine as tested for ~64 hours and no XRUNS observed.

    Best Regards,

    Suren

  • 0 in reply to Suren Porwar
    Prodigy 120 points

    Interesting theory, but I think too easily disproved because the same test run on any other hardware does not result in the same issue.

  • 0 in reply to inojosh
    TI__Prodigy 140 points

     This is not theory. It is clearly observed that gstreamer doesn't have the same view of buffer size which is actually getting set if using dmix/dshare plugin.

    For e.g. if I launch the provided gstreamer command with provided asound.conf and with prints enabled in driver:

    GST_DEBUG="*alsa*":6 GST_DEBUG_FILE="/run/alsa.txt" gst-launch-1.0 audiotestsrc freq=440 ! alsasink device=playback_dshare  -v      
    Setting pipeline to PAUSED ...

    $dmesg

    [ 1179.603924] udma: buf_addr: f7880000, buf_len : 66156, period_len : 22052, dir : 1, tr0_cnt0 : 22052, tr0_cnt1 : 1, tr1_cnt0 : 0, num_tr : 1

    As per the kernel print that I put, it shows buffer length as thrice of period size (in bytes)

    but the gstreamer logs show buffer size as twice of period size :

    grep -inr "buffer size" /run/alsa.txt                                                                                                                                                    
    27:0:00:00.164735830  1271 0xffffa8000b70 DEBUG                   alsa gstalsasink.c:571:set_hwparams:<alsasink0> buffer size 11026, period size 5513

    NOTE: Gstreamer logs are in frames and not bytes

    So, gstreamer is assuming the buffer-size as something different then what is actually getting set while using dmix, it may or may not be the only issue but it doesn't make sense to repeat the test without making sure gstreamer has correct view of buffer size and period size as being actually set and hence we recommend to put same buffer-size and period-size in asound.conf and gstreamer command as shared in previous comment always before launching.

    2) With the audiotestsrc ! alsasink pipeline, you are running both the elements on same thread and I see that upstream element i.e. audiotestsrc is also generating real-time audio pattern using CPU and sending to downstream, in case there one of the element is delayed momentarily due to scheduling latency delay or some other reason it will block the other element. That is the reason we recommend putting a queue element in between as shared in previous comment.

    3) I don't see any evidence yet about mcasp/dma software/hardware or clock skew causing the issue, if there was indeed some issue then it should ideally also occur without using dmix plugin, so not sure if dmix plugin is doing some extra which is not being latched onto by gstreamer (for e.g. buffer-size/period-size was one of the things)

    4) I can't comment on how it runs fine with some other hardware (maybe the skew between dmix settings and gstreamer settings is not much or not impacting or it is defaulting to some other buffer configurations or the environment there is providing better CPU latencies) but I would not recommend to test with the same pipeline without making sure dmix and gstreamer have consistent view of buffer configurations.

    Is it possible for you to try at your end with provided recommendations i.e. adding a queue element in between and making sure buffer-size and period-size are set as same for both gstreamer and asound.conf as shared in previous comment by Suren  ?

    Regards

    Devarsh