Topic: Micro freezes audio [Solved] (Read 4348 times)

erviv · « **on:** October 07, 2020, 02:50:20 pm »

I have had this problem in the past, more so with debian jessie. With Stretch is was less apparent. Now with Buster I have noticed more frequent audio freezes. I moved my library and audio files to a USB connected external HDD connected directly to my rpi. It previously was connected over the LAN to a different HD connected via USB to my router. I noticed some apparent random micro-freezing and decided to move my files to the local HDD. Have not noticed any appreciable difference. I am running version 27.0.10. I would describe the freezes at about 1/4 to 1/2s.
My audio options are set as no decoding, and prebuffering is 10s, full file loaded not decoded into memory.
ex Source 48 khz 24 bit 2ch Internal 48khz 64bit 2ch (no idea about the 64bit)

Suggestions

bob · « **Reply #1 on:** October 08, 2020, 08:20:47 am »

Please test with memory playback disabled, thanks.

erviv · « **Reply #2 on:** October 10, 2020, 06:35:44 am »

Ok, with memory playback disabled the problem seems to be diminished. I have still heard some micro-freezes, but they seem less frequent and shorter. I will listen some more when I get a chance to ensure that the micro-freezes are not caused by some other activity on my pi.
I had thought playback from memory was supposed to resolve this type of problem which was why I selected that option.
Thanks for the advice.

bob · « **Reply #3 on:** October 10, 2020, 10:56:35 am »

Quote from: erviv on October 10, 2020, 06:35:44 am

Ok, with memory playback disabled the problem seems to be diminished. I have still heard some micro-freezes, but they seem less frequent and shorter. I will listen some more when I get a chance to ensure that the micro-freezes are not caused by some other activity on my pi.
I had thought playback from memory was supposed to resolve this type of problem which was why I selected that option.
Thanks for the advice.

You can also fiddle with the buffering parameters in Audio Device Settings. Increasing them both may help.

erviv · « **Reply #4 on:** October 10, 2020, 03:25:23 pm »

I have increased them to 10 from 6, but can fiddle some more. This afternoon there was perhaps only one occurrence in about two hours of listening.

Zhillsguy · « **Reply #5 on:** October 10, 2020, 07:27:57 pm »

Are your sample rates set to no change? What device are you using for audio out?

erviv · « **Reply #6 on:** October 10, 2020, 08:12:19 pm »

Sample rates are set as no changes. For audio out is hw:card=b20,dev=0[ALSA] Bryson USB Audio 2.0, Direct Hardware device without any conversion

I bumped the prebuffering to 20 sec to see what that will do.
Having listened now with prebuffering at 20sec I do ice any change and still get a infrequent microfreeze.

Zhillsguy · « **Reply #7 on:** October 10, 2020, 09:31:13 pm »

Are you using RPi4's?

erviv · « **Reply #8 on:** October 11, 2020, 06:34:37 am »

Pi’s are 3B

Zhillsguy · « **Reply #9 on:** October 11, 2020, 01:36:17 pm »

Honestly you may have to live with an occasional glitch with older Pi's especially playing hi res audio.
I/O bandwidth may be the bottleneck. Try playing nothing but MP3's and see if it helps, this may help troubleshooting.
I think you should use the 5GHz wifi for network and media file access if practical, it may be the most reliable bandwidth in and out.
You may be able to modify or disable auto-import so it isn't trying to check/update your library during playback.
You can try using DietPi as the OS, I felt it was a little lighter than RPi OS, ymmv.

There may be other things that can be done as mentioned in other threads.

JimH · « **Reply #10 on:** October 11, 2020, 01:50:24 pm »

Power can also cause problems. You can't use a USB drive without better power. The RPi site has information on power.

erviv · « **Reply #11 on:** October 11, 2020, 03:36:28 pm »

Thanks Jim and Zhillsguy for the feedback. I switched the music files from a wired connection to my router attached hard drive to music files directly attached to my rpi via USB to avoid these issues. I think it may have helped.
The rpi 3b wifi only operates on the 2.4 GHz. I think dual bands started with model 3B+.
I already have auto import turned off.
It is more of a nuisance, so I will continue to tinker, but can certainly live with it.
I just double checked the location of my library files and realized that I had it saved to my local HDD, so I have now moved it to my SD card, as this seems the preference for faster performance. I am now in the process of rebuilding thumbnails and will let this run overnight before further checks.
As an aside I usually use JRemote for playing my music. I notice that when I update my playlists the pi might hang momentarily, and wonder if there are some other periodic communications.

erviv · « **Reply #12 on:** October 13, 2020, 06:50:50 am »

Listened to my music last night and still had a couple of micro freezes. If I recall correctly I had a similar problem when running on Jessie which eventually went away, or was significantly less, when I switched to stretch, and is back again with buster. Anyhow I might explore Dietpi, although it looks like dietpi isn’t supported by JRiver. Or perhaps just wait and see how different upgrade combinations of raspian and MC get along.
Again thanks for the help.

Zhillsguy · « **Reply #13 on:** October 13, 2020, 01:01:10 pm »

I get an occasional glitch on my RPi4, but typically I am listening to Radio Paradise flac, and the glitch comes close to the track changes. Still tweaking that.

JRiver runs fine on DietPi, it is Debian based. It is a little tricky to install, but not too bad.

A couple of other somewhat convoluted options that may be tried or tweaked, YMMV...

1. Try using Berryboot which can put the OS on an external USB drive. I noticed a small improvement on my Pi 4 with an SSD in an enclosure. On the older Pis a single USB buss is shared, different animal.

2. Using the two Pi's, install Volumio on P1 with the media files on the external USB and DAC connected. If the Bryson DAC is recognized by Volumio you are in business. Activate DLNA and control playback with JRiver installed on P2. I believe Volumio can share the media files for network access by P2 for import.

This setup can be modified for control and playback in a few different ways for trial, but I am not sure if anything will help. You may end up back where you are now. Using Volumio's browser access for playback control is also an option.

erviv · « **Reply #14 on:** October 21, 2020, 04:32:42 pm »

Using google search on optimizing Linux audio I came across a suggestion to adjust the following file /etc/sysctl.conf with the addition of the line vm.swappiness = 10

So far since I made the change and rebooted my micro freezes have been diminished. I was going to say gone, but I have just had one.

JimH · « **Reply #15 on:** October 21, 2020, 05:17:28 pm »

Are you using memory playback? If so, try turning it off.

erviv · « **Reply #16 on:** October 21, 2020, 08:48:29 pm »

JimH, thanks, that was Bob’s suggestion in response to my original posting. I did turn off memory playback based on his recommendation and saw some improvement, but that did not eliminate the issue.

Zhillsguy · « **Reply #17 on:** October 22, 2020, 01:37:47 pm »

Did you try using Volumio? Volumio and MC work pretty well together.

erviv · « **Reply #18 on:** October 24, 2020, 08:06:57 pm »

Zhillsguy, I expect what you describe might work. It does add some complexity with an additional interface to the audio stream. I have no familiarity with volumio.
I note that when I play audio from MC to my iPad via JRemote I get no audio freezes. So that chain is fine, yet playing out via USB to my DAC does have micro freezes. I understand this is a completely different flow path.

Gedeon · « **Reply #19 on:** October 25, 2020, 02:45:09 am »

An easy test could be to launch MC with nice/ionice to increase/decrease process priority for CPU or I/O access

erviv · « **Reply #20 on:** October 25, 2020, 06:37:15 am »

Ok, I did a search on nice and ionice. I take it the idea is to use these commands in terminal, but I don’t know what pid to use as this varies on restart of the application.

Gedeon · « **Reply #21 on:** October 25, 2020, 08:57:33 am »

With pidof you can get the pid.

$ pidof mediacenter27
3599
$ ionice -c2 -n0 -p3599

erviv · « **Reply #22 on:** October 25, 2020, 09:50:04 am »

Thanks for the suggestion, it gave me something new to investigate and learn.
Based on the example you provided I checked the current class and priority of Mediacenter27.
First I ran pidof mediacenter27 and learned in this instance the pid was 1079. I confirmed that the pid changes with each restart of MC; the new one now being 17255. So I checked ionice -p 17525. The return was none; prio 0. Based on what i am reading from the online linux manual I this means class best effort ( if no class is specified the process takes none or 0 the same as 2 best effort, and priority 0 is the highest priority). I stopped and restarted MC27 again just to confirm the class and priority remained the same with each change of pid and yes it did (as to be expected).
So I think the system is already set as per your suggestion -c2 (best effort) -n0 (highest priority).

Gedeon · « **Reply #23 on:** October 25, 2020, 10:12:40 am »

Just try If ionice or nice finally solves microfreezes

If any of those works then a small script could be added to automatically start always MC with the modified priority.

Gedeon · « **Reply #24 on:** October 26, 2020, 12:58:49 am »

You can try "nice" with negative values (to increase CPU priority for MC) and ionice in order to add MC to real time class, instead of best effort.

mwillems · « **Reply #25 on:** October 26, 2020, 09:28:09 am »

MC automatically configures itself to use realtime thread priorities as long as the user running MC is in the "audio" group.

Erviv, what's the output of "groups" for your user?

erviv · « **Reply #26 on:** October 26, 2020, 12:27:36 pm »

MWillems, here is the output of groups pi

pi@raspberrypi:~ $ groups pi
pi : pi adm dialout cdrom sudo audio video plugdev games users input netdev spi i2c gpio
or
pi@raspberrypi:~ $ id
uid=1000(pi) gid=1000(pi) groups=1000(pi),4(adm),20(dialout),24(cdrom),27(sudo),29(audio),44(video),46(plugdev),60(games),100(users),105(input),109(netdev),997(gpio),998(i2c),999(spi)

mwillems · « **Reply #27 on:** October 26, 2020, 12:28:47 pm »

Ok, then I suspect it's unlike to be a cpu thread priority issue.

bob · « **Reply #28 on:** October 26, 2020, 12:44:34 pm »

Quote from: mwillems on October 26, 2020, 12:28:47 pm

Ok, then I suspect it's unlike to be a cpu thread priority issue.

Or maybe it's a combination of issues with the realtime kernel?
You could try removing MC from using realtime priority by deleting the rtprio entry on:
/etc/security/limits.d/mediacenter27.conf
and rebooting so it will fall back to using TS priorities (much less aggressive).

erviv · « **Reply #29 on:** October 26, 2020, 12:47:31 pm »

OK thanks. I do have the following added to the /etc/security/limits.conf file, although I am not sure if it is still required.

# End of file
pi - rtprio 100
@audio - rtprio 100
Checking threading reveals this;

pi@raspberrypi:~ $ ps -T -eo pid,tid,class,rtprio,ni,pri,comm | grep mediacenter
22420 22420 TS - 0 19 mediacenter27
22420 22573 TS - 0 19 mediacenter27
22420 22575 TS - 0 19 mediacenter27
22420 22577 TS - 0 19 mediacenter27
22420 22588 TS - 0 19 mediacenter27
22420 22649 TS - 0 19 mediacenter27
22420 2525 TS - 0 19 mediacenter27
22420 2526 TS - -17 36 mediacenter27
22420 2527 TS - 18 1 mediacenter27
22420 2548 RR 1 - 41 mediacenter27
22420 3711 TS - 10 9 mediacenter27
22420 3712 TS - 0 19 mediacenter27
pi@raspberrypi:~ $
I take it the line showing a class of RR and rtprio being 1 is what indicates threading is working as desired.

bob · « **Reply #30 on:** October 26, 2020, 12:51:19 pm »

Quote from: erviv on October 26, 2020, 12:47:31 pm

OK thanks. I do have the following added to the /etc/security/limits.conf file, although I am not sure if it is still required.

# End of file
pi - rtprio 100
@audio - rtprio 100
Checking threading reveals this;

pi@raspberrypi:~ $ ps -T -eo pid,tid,class,rtprio,ni,pri,comm | grep mediacenter
22420 22420 TS - 0 19 mediacenter27
22420 22573 TS - 0 19 mediacenter27
22420 22575 TS - 0 19 mediacenter27
22420 22577 TS - 0 19 mediacenter27
22420 22588 TS - 0 19 mediacenter27
22420 22649 TS - 0 19 mediacenter27
22420 2525 TS - 0 19 mediacenter27
22420 2526 TS - -17 36 mediacenter27
22420 2527 TS - 18 1 mediacenter27
22420 2548 RR 1 - 41 mediacenter27
22420 3711 TS - 10 9 mediacenter27
22420 3712 TS - 0 19 mediacenter27
pi@raspberrypi:~ $
I take it the line showing a class of RR and rtprio being 1 is what indicates threading is working as desired.

Yes. RR is the playback thread.
Like I said just above your message you might want to try to diasble that for testing.

erviv · « **Reply #31 on:** October 26, 2020, 12:52:23 pm »

Bob, I have commented out the two lines in the /etc/security/limits.conf file as per below. I will see what happens.

# End of file
# pi - rtprio 100
# @audio - rtprio 100

bob · « **Reply #32 on:** October 26, 2020, 12:54:10 pm »

Quote from: erviv on October 26, 2020, 12:52:23 pm

Bob, I have commented out the two lines in the /etc/security/limits.conf file as per below. I will see what happens.

# End of file
# pi - rtprio 100
# @audio - rtprio 100

Make sure to do the one I mentioned as well. It will get added to the mix.

erviv · « **Reply #33 on:** October 26, 2020, 01:02:34 pm »

Bob, thanks, I read your advice too fast. I will also do the file you pointed out, as adjusting the first file has had no change.
I have now edited the file /etc/security/limits.d/mediacenter27.conf
# Allow the Media Center user (which should be in audio group) the ability to c$
# @audio - rtprio 100
# @audio - nice -20

Now for a reboot and test.

Gedeon · « **Reply #34 on:** October 26, 2020, 01:05:56 pm »

So, now you have both (DAC and HD) attached directly to pi through usb.

When only the DAC was attached there were no issues?

Do both devices have their own power supply ?

bob · « **Reply #35 on:** October 26, 2020, 01:13:38 pm »

Quote from: erviv on October 26, 2020, 01:02:34 pm

Bob, thanks, I read your advice to fast. I will also do the file you pointed out, as adjusting the first file has had no change.
I have now edited the file /etc/security/limits.d/mediacenter27.conf
# Allow the Media Center user (which should be in audio group) the ability to c$
# @audio - rtprio 100
# @audio - nice -20

Now for a reboot and test.

You could probably leave the TS enabled. It will give MC more room to work on priorities without using realtime priorities.

erviv · « **Reply #36 on:** October 26, 2020, 01:19:35 pm »

Gedeon: Yes there were mirco freezes with only the DAC attached via USB. The music files were coming in from a Hard drive attached by USB to my router which in turn was connected to my rpi via an ethernet cable. I moved to a different HDD attached directly to my pi, via USB, as an attempt to eliminate a device in the audio path (in this case eliminating the router and ethernet cable.) II heard that this had resolved some peoples problems.
The Brysotn DAC is self powered and the HDD is powered from the USB connection to the rpi.

Bob. I am still getting audio momentary freezes after adjusting the suggested file(s).

Bob: I see what I missed. I"ll re-instated as follows:
# Allow the Media Center user (which should be in audio group) the ability to change nice priorities and set real-time for the output thread.
# @audio - rtprio 100
@audio - nice -20

erviv · « **Reply #37 on:** October 26, 2020, 01:34:55 pm »

Still the same.
I will explore my second Pi which is on a different DAC and the old NAS audio files and see what it is doing so far as microfreezes. - Yes it also has microfreezes.
I might swap the it out with this one and try to eliminate this is related to this specific unit.
- Since the bsmt pi also has microfreezes I am not going to try this.
The SD cards are both the same brand and new?
I did have issues in the past with the basement (bsmt) Pi but did have a combination of MC/raspian versions where the microfreezes seemed to have disappeared. However since moving to buster the problems have returned.

Is there a way to tell what activity is trying to take over the audio output 'thread', or why this is allowed ? (seems to block and then release the thread). Or is that more of a question for the raspian forums?

JimH · « **Reply #38 on:** October 26, 2020, 03:15:24 pm »

If you haven't done so, read about power problems on the RPi site. You can't safely use a USB device on it unless it's powered separately. You may have problems. I had crashes a few years ago when I had an unpowered USB hard drive on a Pi. The solution was better power.

erviv · « **Reply #39 on:** October 26, 2020, 03:20:31 pm »

A further set of observations.
When I use my bsmt pi as a renderer with the server being on my MacBook pro I get micro freezes.
If I reverse the process and use the pi as the server and the MacBook Pro as the renderer, I don't appear to get microfreezes.
I don't get micro freezes playing MC directly on my MacBook Pro, either.
When I use the pi as a server (?) to JRemote on my ipad I don't get micro freezes.
When I use my family room pi as server to my bsmt pi as renderer I do get micro freezes.
Micro freezes occur on my bsmt pi whether playback is through my DAC via USB or through my TV via HDMI.

Playback on the pi seems to be the common element in these micro freezes.

Jim H, Yes I have looked at the power supply. My one supply is an official rpi power supply, the other is not. Both pi's exhibit the same issues. As per above, I can get sound with no freezing out, just not to where I would like it. However I can't discount power supply as the problem.
I think I will have to live with the problem for the time being.

erviv · « **Reply #40 on:** October 27, 2020, 04:12:21 pm »

So I investigated using volumio as a renderer on my Pi with JRiver on my second Pi asa server. While i didn’t notice any microfreezes I did have a very infrequent audio stutter. Also with volumio as a renderer, or perhaps any renderer, volume only seems controllable from the client ( as opposed to from JRiver or JRemote.
I like the simpler interface with JRiver. I will see what happens when I replace the power supplies sometime in the next few months.
Meanwhile the microfreezes are infrequent enough that for my purposes I will stay with my original set up.
Thanks again.

erviv · « **Reply #41 on:** January 21, 2021, 09:27:09 am »

Funnily enough one of the items I never considered, but was a common denominator between my two pi's, was the SD card. This week I ran the raspberry pi diagnostics tool against both pi's. Both SD cards failed the test, specifically on writing speed. They were both the same name brand SD cards. Read speed passed although not by a lot. Writing failed miserably.
I purchased two new SD cards of a different brand. I reloaded raspbian on the pi's and ran the diagnostics again. Both new cards passed with flying colours. I re-installed JRiver without a glitch.
I initially used the new card on my new rpi4 and had no issues. I played music the full day and no sound freezes. So I thought to try the same make on my rpi3 and have not yet heard any micro freezes.
Interesting. So I thought I would post the results here in case others experience a similar issue.

bob · « **Reply #42 on:** January 21, 2021, 10:03:26 am »

Quote from: erviv on January 21, 2021, 09:27:09 am

Funnily enough one of the items I never considered, but was a common denominator between my two pi's, was the SD card. This week I ran the raspberry pi diagnostics tool against both pi's. Both SD cards failed the test, specifically on writing speed. They were both the same name brand SD cards. Read speed passed although not by a lot. Writing failed miserably.
I purchased two new SD cards of a different brand. I reloaded raspbian on the pi's and ran the diagnostics again. Both new cards passed with flying colours. I re-installed JRiver without a glitch.
I initially used the new card on my new rpi4 and had no issues. I played music the full day and no sound freezes. So I thought to try the same make on my rpi3 and have not yet heard any micro freezes.
Interesting. So I thought I would post the results here in case others experience a similar issue.

By default, MC writes to the disk to buffer incoming audio so that would explain your result.
You can disable that behavior, with a possible small loss in functionality (seeking on certain streams), by checking the "disable audio buffer to disk" under MC's Media Network options.

erviv · « **Reply #43 on:** January 21, 2021, 11:51:39 am »

Bob, does that apply only to audio being played over a network (media server) or does MC write to the buffer when playing standalone? I ask because the suggestion is to disable buffer to disk under Options/Media Network.

Thanks for identifying the “why”.

JimH · « **Reply #44 on:** January 21, 2021, 12:33:10 pm »

That's a network setting.

INTERACT FORUM

Author Topic: Micro freezes audio [Solved] (Read 4348 times)