Audio playback under Android JellyBean stops sporadically on TC2 with release 13.03

[Robin Randhawa]

1. Release 13.03 suffers from a problem on TC2 where audio playback under
    Android JellyBean sporadically stops working. The problem is localised in that
    there is no system instability - the audio simply stops - while the system
    remains fully functional.

2. There is a strong possibility that this problem is related to the Android
    JellyBean audio adaptation driver especially given that the ALSA driver in the
    kernel is known to work fine (verified using 'raw' playback methods such as the
    aplayer CLI utility).

3. Since audio playback is a key part of the power-performance scoring
    on TC2 (either in isolation or when used as a composite workload with
    BBench, for example), this presents a problem since the
    power-performance scores end up looking very different when the audio
    playback fails. The problem was first discovered when validation reports
    highlighted significant 'improvements' in the power numbers for the
    audio-only use-case.

[Tixy (Jon Medhurst) (tixy)]

I'm struggling to reproduce this. Playing various music files through the music app and running the audio workbench test through 20 iterations worked fine for me on an 13.03 image. Well, when I say fine, I mean it has the tortuous warbly sound it's always had, presumably due to frame drops/lag from poor interrupt/cpuidle latency.

When first running the workbench tests I had no sound, but realised that the scripts Linaro uses don't download the test files unless you edit them to change audio_config_download to true. After changing that the tests actually played music and used a lot more power. I assume that the origin or this bug report isn't due to a similar issue and 'sporadically stops working' means stops halfway through playback and doesn't work again until a reboot?

Is there a know configuration where this bug has been seen? I'm using the default config from the release, but if the workbench tests are using there own device-trees for booting with different cpu cores or messing with interrupt affinity that may have bearing on things and would be useful to know.

[Sudeep Holla (sudeep.holla)]

As you have already described it's pretty difficult to reproduce this issue.
Sometimes it takes long time(aboyt 4-5hrs). The usecase is quite simple,
just play a single mp3 in loop using Music player. The progress bar continue
to show progress but no audio output when the issue is hit. You can also see
that no more aaci-pl041 Tx interrupts occur.

So one way to find if audio has stopped working to just check Tx interrupt
count instead of actually hearing it which can be annoying based on the music
in the album :)

This may not be true always, but still I observed this issue can be seen at faster rate
with PSCI configuration(i.e. with secure firmware enabled). As I have mentoned it
may not be true always.

[Tixy (Jon Medhurst) (tixy)]

I left an mp3 track looping for 15 hours and did not see this bug. I've also run 500 iterations of the audio workbench, again without apparent problems. Before I retry all this again with PSCI enabled can I get confirmation of the setup being used when this bug is seen? I.e.

 - Is the board booting on and A7 or A15 core?
 - Is the rootfs on MMC or USB drive?
 - Which bootloader is being used, Bootmon or UEFI, and which version?
 - Can I have the board.txt file?
 - It is the Linaro 13.03 release being tested?
 - The device tree and kernel being used is that from the Linaro release?

Thanks

[Sudeep Holla (sudeep.holla)]

On 02/05/13 09:52, Tixy (Jon Medhurst) wrote:
> I left an mp3 track looping for 15 hours and did not see this bug. I've
> also run 500 iterations of the audio workbench, again without apparent
> problems. Before I retry all this again with PSCI enabled can I get
> confirmation of the setup being used when this bug is seen? I.e.
>
Do you mean you were able to hear audio after 15hrs? Because on my
set-up I have always hit this issue between 4-8hrs.

> - Is the board booting on and A7 or A15 core?
Mostly we do most of testing with A7 as boot, but not mandatory for this
usecase.

> - Is the rootfs on MMC or USB drive?
USB

> - Which bootloader is being used, Bootmon or UEFI, and which version?
Bootmon without PSCI, SecF/W + UEFI with PSCI config

> - Can I have the board.txt file?
It's standard, in fact we aligned with 13.03 Linaro release.

> - It is the Linaro 13.03 release being tested?
The issue was seen even with 13.01 release, just that we started seeing
during 13.03.

> - The device tree and kernel being used is that from the Linaro release?
Yes

Punit here also struggled to hit this issue. Since we have seen this on
3 boards we can't blame it on boards I believe.

Give a try with PSCI config. I gave a try yesterday and was able to see
with PSCI within 20-30mins while without PSCI it took 6hrs.

Regards,
Sudeep

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

[Sudeep Holla (sudeep.holla)]

> I left an mp3 track looping for 15 hours and did not see this bug. I've
> also run 500 iterations of the audio workbench, again without apparent
> problems. Before I retry all this again with PSCI enabled can I get
> confirmation of the setup being used when this bug is seen? I.e.
>
Do you mean you were able to hear audio after 15hrs? Because on my
set-up I have always hit this issue between 4-8hrs.

> - Is the board booting on and A7 or A15 core?
Mostly we do most of testing with A7 as boot, but not mandatory for this
usecase.

> - Is the rootfs on MMC or USB drive?
USB

> - Which bootloader is being used, Bootmon or UEFI, and which version?
Bootmon without PSCI, SecF/W + UEFI with PSCI config

> - Can I have the board.txt file?
It's standard, in fact we aligned with 13.03 Linaro release.

> - It is the Linaro 13.03 release being tested?
The issue was seen even with 13.01 release, just that we started seeing
during 13.03.

> - The device tree and kernel being used is that from the Linaro release?
Yes

Punit here also struggled to hit this issue. Since we have seen this on
3 boards we can't blame it on boards I believe.

Give a try with PSCI config. I gave a try yesterday and was able to see
with PSCI within 20-30mins while without PSCI it took 6hrs.

[Tixy (Jon Medhurst) (tixy)]

On Thu, 2013-05-02 at 09:22 +0000, Sudeep KarkadaNagesha wrote:
> > I left an mp3 track looping for 15 hours and did not see this bug. I've
> > also run 500 iterations of the audio workbench, again without apparent
> > problems. Before I retry all this again with PSCI enabled can I get
> > confirmation of the setup being used when this bug is seen? I.e.
> >
> Do you mean you were able to hear audio after 15hrs?

Yes.

From your replies about the config being tested it sounds like I was
using exactly the same. So the difference with my test would have been:

- I added a few LOGE messages to audio.primary.vexpress.so to show if
any of the error paths we're being hit, they weren't.

- I had ADB connected and a script polling every 10 seconds to
get /proc/interrupts and logcat.

I'll give PSCI booting a go, without ADB being connected and a stock
audio.primary.vexpress.so. That was my next plan but wanted to make sure
I had the same config as well...

[Tixy (Jon Medhurst) (tixy)]

My test with booting with PSCI on a completely unmodified 13.03 image ran for 16 hours and the music was still playing OK.

[Tixy (Jon Medhurst) (tixy)]

Tracking of this bug has moved to a different system at http://cards.linaro.org/browse/ARM-24

[Ryan Harkin (ryanharkin)]

This bug is now tracked in Bugzilla: https://bugs.linaro.org/show_bug.cgi?id=143