Sound cuts out on Raspberry Pi

I have been running my bellringing progam (which I wrote on the BBC 28 years ago) on my Raspberry Pi.
It seems to run perfectly, but after a random time (which can be seconds or minutes) the sound cuts out completely, although the screen shows that it is still printing out the changes.
It is as though the “Mute” button has been pressed.
The sound does not come back while the program is running, but if I go back to the desktop and rerun it, the sound is O.K. at the beginning before cutting out again.
Can anybody help?
Alan

Interesting – the same is also true of the background music in !Zool (cuts out but then starts again once a different track has been briefly used, eg. between levels). I wonder whether this is the same issue?

I have also noticed this behaviour from ArcEm, but not tested it off of a Raspberry Pi, so I am not sure if this is limited to the Pi.

Whilst I am thinking about it, I did noticed that DiskSample appeared to go silent on my Mk1 Pi, from time to time, and only a reboot fixed it. The same setup (card moved over) worked fine on a MkII. Sadly my MkI has died.

I seem to (vaguely) recall that this can happen if you overfill the sound buffer. Are you checking to make sure it has space available?

Chris: As this seems to be happening in software that worked previously, perhaps the question could be rephrased as:

- Is there a reason the RPi’s sound buffer might become exhausted more rapidly than on other variants?

In September, I spent some time adding a status of each of the ports. Reading the Raspberry Pi one seems relevant here.

It is not a case of the buffer being exhausted. It is a case of the buffer being overfilled and therefore thinking that it is exhausted. Slower machines did not seem able to stuff so much data into the sound buffer quickly enough to fill it. Newer machine are now fast enough for this to happen. Simply check the sound buffer has some space before stuffing it.

The call SYS “Sound_QFree” can help, or restrict BASIC in the number of queued sounds it places in the buffer at one time.

I too now have the same problem as Alan on my bellringing program Stringing. I’ve been running Stringing on my Pi since February and in over fifty hours of use had never had a problem until a recent upgrade to the RISCOS/IMG. Now I have exactly the same symptoms as Alan.
I don’t think it is caused by the sound buffer overflowing as adding *FX26 commands to clear the buffer between each sound command does not cure the problem. The problem does seem to be time-related in some way. Speeding up the program by a factor of 2 or 3 seems to give longer periods before sound failure and a less wide variation in the random time to failure, though I need to do more tests to be sure. I am sure of one thing: speeding up the program to maximum speed reduces the failure rate. In fact in the tests I have done so far at full speed I haven’t had a sound failure, even after an hour or more’s running. At this speed the program is generating over 2000 changes a minute and issuing approx. 250 Sound commands a second.
The cause of the problem seems to lie in a change to RISCOS/IMG sometime between February and June 2013. It would be good to find the solution

I have today reported the problem as a bug, Ticket #376

Chris mentioned it being the buffer being overfilled, why would the RO Channel Handler call the buffer fill code more than it needs too? It was my understanding that if your fill code is called, you add another N bytes to the buffer. N being the buffer length you’ve previously got from Sound_Configure.

I’ve recently modified TrackerModule to get Magic Pockets working on RO5 and as part of that work, I recoded it to query the buffer size and the frequency, so it worked on any machine. It however goes silent after a while randomly.

When it stops, other sound carries on working, so either RO has stopped calling the buffer fill code or it’s not merging the buffer with the sound output.

At the point it stops, no other sound is occuring. For example sitting it the intro sequence of Magic Pockets it may randomly go silent before it gets to demo mode.

I attended the MUG meeting yesterday.
One of the people there had the beta version of RISC OS running on his Raspberry Pi.
We ran my ringing program on it for 40 minutes, and the sound didn’t cut out!
How do I load the beta version? I’ve downloaded it from ROOL as a zip file but
can’t see how to load it.

Hi Alan,

As discussed yesterday it is a little long winded.

First best to upgrade to the latest beta harddisc image from the software downloads section on this site.

Download the self extracting version and change it’s file type to &FFC and then double click on it to extract the hard disc image.

Double click on !Boot, select Boot and then install and then open up the directory just created and drag the new !Boot to the install window and merge the files.

Next copy all the new applications over the existing ones on your hard drive. Note you may need to change the access to unprotect on your existing ones to enable this to happen.

Then shut down you machine and check it works OK, if you get issues with the monitor either not displaying correctly or not saving the monitor type then you may need to rename the !Boot>Choices>Boot directory to something else and then reboot and reconfigure your system from scratch.

Finally once you have a working copy of a system then Shift>Select the mouse on !Boot and locate and open up the Resources and then the PCLoader directory. This will display contents that include a file name RISCOS/IMG.

Open up the new ROM zip file and extract the file named riscos to the RAMDisc and then change it’s name to RISCOS/IMG. Then change it’s file type to &692 and copying it over the old RISCOS/IMG file.

Finally reboot and you should have a new ROM and harddisc image running.

If this is a little daunting then wait until ROOL produce a later version of the official Pi image or bring your Pi along to the next MUG meeting in March or along to the South West show on 1st March where I’m sure people can help update the Pi setup you have.

I tested sound on the 14-01-14 alpha and found other issues, SoundDMA for example would hang during the boot sequence and a lot of sound wasn’t outputting at all. I couldn’t see any documented changes listed on the revisions list recently, so I’m not entirely sure why I was seeing these issues.

Has anything changed on the audio stack since the 04-12-13 alpha?

Previously in-game music would stall at a random point, now it stalls after the first buffer fill. WaveSynth, StringLib and Percussion however seem to be unaffected.

Jon: Have you tried today’s ROM? Both 8-bit and 16-bit sound seems to be working fine for me. However, I have recently been seeing the occasional hang on startup initialising SoundDMA, and I haven’t yet checked if the “sound suddenly stops” issue still occurs. If you were only testing with an older ROM then it’s possible the video bug was causing some sound issues as well.

Yes, have tried today’s ROM, which promoted me to raise it. Is it possible to download previous nightly builds so I can see at what point it started being an issue?

I know it started after 04-12-13 and prior to 14-01-13

Unfortunately not; only the latest builds are kept on the server.

Is it possible to download previous nightly builds so I can see at what point it started being an issue?

What dates?

Silly, boy Steven – read further up…

14 revisions, totalling 33.4MB (first 2013-12-04, last 2014-01-13)
Do you have an available FTP server?

I do…drop me a mail for details: jon at jaspp dot org dot uk
Or just send them via eMail if possible.

Or just send them via eMail if possible

Avoiding filling a mailbox – let me know which.

Hi John,
Password error on the FTP, so I mailed them to save time.

eek! 39MB post MIME.

Jeffrey – I’ve tested the following builds. Steve – thanks for eMailing them.

07-12-13 – in-game music working
10-12-13 – in-game music working
16-12-13 thru 24-12-13 – unable to test due to MODE change issue
02-01-14 – no in-game music

All we can say is that this issue (which is a separate issue to the OP) started sometime between 11-12-13 and 01-01-14. There’s obviously a gap I’ve not tested between 11-12-13 and 15-12-13 unless someone has the builds and can eMail them to me.

With regard to SoundDMA hanging, I’ve not seen it happen on the 04-12-13 build which I boot several hundred times a day. I did see it on the 14-01-14 build after a few boots and haven’t tested inbetween due to the previously mentioned MODE change issue.

With regard to the OP issue, it’s been there as long as I can recall. It’s reproducible simply by leaving something with sound running. I’ve seen/heard it in Zarch when it’s in demo mode for example, Zarch doesn’t do anything fancy with audio – it uses Percussion and WaveSynth and barely touches the OS other than via OS_WriteC / OS_WriteS and OS_Byte 112 / 113 to swap frames.

What I haven’t established, is if the buffer fill code is still being called after it goes silent, so at this stage I’m unsure if it’s an internal RO issue or related to RO’s interaction with the hardware.

What I haven’t established, is if the buffer fill code is still being called after it goes silent, so at this stage I’m unsure if it’s an internal RO issue or related to RO’s interaction with the hardware.

On 18 May 2006 I posted the item below on the A9home list, identifying the problem with BASIC sending lots of SOUND commands and no-one shot me down in flames. I presume the issue is still there in RISC OS?

BASIC does not check the remaining space in the OS sound buffer before adding sound commands to it. On a fast machine such as A9 this can mean that BASIC can add sound commands faster than they can be played (as they are of course *played* at the same speed). If the sound buffer overfills, this can mean it takes an undefined time to recover as it is implemented as a circular buffer on RISC OS. Use the SWI Sound_QFree to check free space in the buffer to avoid overfilling.

I can see why that would be a problem however I don’t believe this is the same issue. Sounds aren’t being flooded into the buffer, a soundtracker for example is simply fulfilling a buffer fill request made by the OS. The length of that buffer and frequency rate at which the fill code is called are under the control of the OS.

There’s obviously a gap I’ve not tested between 11-12-13 and 15-12-13 unless someone has the builds and can eMail them to me.

The builds between those dates should be identical, it doesn’t look like anything was checked into CVS during that time.

Is it just with ADFFS that you’re seeing sound immediately fail, or is it happening with other software too? The standard OS 8-bit sound generators, QTM, Zool (Iyonix version – which I’d assume still uses 8-bit sound) and ArcEm (16-bit sound) all seemed to be working fine when I tested the 20-01-14 build yesterday.

Also, are you using HDMI audio or the 3.5mm socket? Unfortunately I don’t have anything to test HDMI audio with. Although if the 8-bit sound generators are continuing to function then that indicates it’s a RISC OS side issue rather than a GPU side one.

What I haven’t established, is if the buffer fill code is still being called after it goes silent, so at this stage I’m unsure if it’s an internal RO issue or related to RO’s interaction with the hardware.

When I was able to reproduce the “sound suddenly stops” issue in the past, it looked like the GPU simply stopped returning processed sound buffers to us, without any obvious indication of an error occuring. This would then cause the OS to stop generating buffer fill requests, and stop it trying to send new buffers to the GPU.