Threaded Mode | Linear Mode

***f1vefour*** · 21st Jun, 2015, 06:15 AM

Thanks for posting that @Skywatch

Oebelchen · 23rd Jun, 2015, 04:47 PM

Thank you Skywatch !!!

You made my day!!!

Now I enjoy stotter-free audio !!!!!!!!!!

Skywatch · 24th Jun, 2015, 01:44 AM

I'm happy it helped you but please remember that I am only the messanger, mkreisl came up with the solution, but I thought it would work for others and so I copied it here.

As it happens I am also very happy today as I finally got my I2S DAC working on a Pi2. Smile

It's an awesome set-up for the price!

Skywatch.

***f1vefour*** · 24th Jun, 2015, 08:27 AM

(24th Jun, 2015 01:44 AM)Skywatch Wrote: As it happens I am also very happy today as I finally got my I2S DAC working on a Pi2. It's an awesome set-up for the price!

Skywatch.

FINALLY, what was the problem?

Skywatch · 24th Jun, 2015, 06:21 PM

(24th Jun, 2015 08:27 AM)f1vefour Wrote: FINALLY, what was the problem?

I'm not really sure, maybe it's fussy about what's in /etc/modules/ or perhaps an updated module or kernel or maybe it's beacuse I did a fresh install.
Wiring, DAC,PSU and settings are all the same as before!

Still, getting it working cheered me up quite a bit!

S,

***Nachteule*** · 2nd Jul, 2015, 06:28 AM

Quote:FINALLY, what was the problem?

The problem is that kodi requires all, and I mean really ALL CPU power if DPRIORITY is set to Yes.
This behavior came with introducing the new priority handling with schedtool. It's working pretty well if nothing runs in the background.
You can make a test: open a ssh session and then walk through kodi's menus, scroll up and down and parallel try to do anything in your ssh session. You will see, this session does not respond until you stop working with kodi.
The same thing happens with audio drivers, they simply get no cpu

I will change

Quote:2 1. is not enough to turn of DP completely. Unfortunately, kodi.bin will be launched with priority 49 and it will newer changed later. So, to turn it completely off you have to modify the file /etc/init/xbmc.conf. Please change the line exec schedtool -R -p 49 -e sudo -u $USER -g $GROUP -s $DAEMON $DAEMON_ARGS $DAEMON_LIRC $DEBUG 2>&1 | grep -v ES30 || : to sudo -u $USER -g $GROUP -s $DAEMON $DAEMON_ARGS $DAEMON_LIRC $DEBUG 2>&1 || :

in the next days, so kodi will only started by schedtool if DPRIORITY=yes

***f1vefour*** · 3rd Jul, 2015, 10:14 AM

Yes nice would likely be better than changing the scheduling priority in this use case, not sure who implemented adjusting the CPU scheduler but if I had to guess I would say mk01 since it likely works a treat on the non-pi XBian supported hardware.

Roy Terhaar · 6th Apr, 2018, 08:47 PM

(2nd Jul, 2015 06:28 AM)Nachteule Wrote:
Quote:FINALLY, what was the problem?
The problem is that kodi requires all, and I mean really ALL CPU power if DPRIORITY is set to Yes.
This behavior came with introducing the new priority handling with schedtool. It's working pretty well if nothing runs in the background.
You can make a test: open a ssh session and then walk through kodi's menus, scroll up and down and parallel try to do anything in your ssh session. You will see, this session does not respond until you stop working with kodi.
The same thing happens with audio drivers, they simply get no cpu

I will change

Quote:2 1. is not enough to turn of DP completely. Unfortunately, kodi.bin will be launched with priority 49 and it will newer changed later. So, to turn it completely off you have to modify the file /etc/init/xbmc.conf. Please change the line exec schedtool -R -p 49 -e sudo -u $USER -g $GROUP -s $DAEMON $DAEMON_ARGS $DAEMON_LIRC $DEBUG 2>&1 | grep -v ES30 || : to sudo -u $USER -g $GROUP -s $DAEMON $DAEMON_ARGS $DAEMON_LIRC $DEBUG 2>&1 || :
in the next days, so kodi will only started by schedtool if DPRIORITY=yes

I am facing a similar stutter audio only issue.
Changing the setting in xbmc.conf helped a bit is my current feeling.
However I could not find the line exec schedtool; maybe it has been replaced or fixed already, I am not sure as this thread is rather old.
Right now I am running kernel 4.14.32+
Kodi 17.6 Git-2017-11-18 433b93a
So far:
- I have checked kodi.log to see if something gets logged when stutter occurs, but no success.
- I have checked with top to see if there is something eating resources or spiking if stutter occurs, but also no results. Everything seems to be normal
Is it possible that the audio driver still does not get enough CPU time to perform it's task?
Any way to check this or other things to check/try?
Any suggestions welcome... thx

***Nachteule*** · 6th Apr, 2018, 09:28 PM

(6th Apr, 2018 08:47 PM)Roy Terhaar Wrote:
(2nd Jul, 2015 06:28 AM)Nachteule Wrote:
Quote:FINALLY, what was the problem?
The problem is that kodi requires all, and I mean really ALL CPU power if DPRIORITY is set to Yes.
This behavior came with introducing the new priority handling with schedtool. It's working pretty well if nothing runs in the background.
You can make a test: open a ssh session and then walk through kodi's menus, scroll up and down and parallel try to do anything in your ssh session. You will see, this session does not respond until you stop working with kodi.
The same thing happens with audio drivers, they simply get no cpu

I will change

Quote:2 1. is not enough to turn of DP completely. Unfortunately, kodi.bin will be launched with priority 49 and it will newer changed later. So, to turn it completely off you have to modify the file /etc/init/xbmc.conf. Please change the line exec schedtool -R -p 49 -e sudo -u $USER -g $GROUP -s $DAEMON $DAEMON_ARGS $DAEMON_LIRC $DEBUG 2>&1 | grep -v ES30 || : to sudo -u $USER -g $GROUP -s $DAEMON $DAEMON_ARGS $DAEMON_LIRC $DEBUG 2>&1 || :
in the next days, so kodi will only started by schedtool if DPRIORITY=yes

I am facing a similar stutter audio only issue.
Changing the setting in xbmc.conf helped a bit is my current feeling.
However I could not find the line exec schedtool; maybe it has been replaced or fixed already, I am not sure as this thread is rather old.

Indeed, it has been changed to this line

Quote:Right now I am running kernel 4.14.32+
Kodi 17.6 Git-2017-11-18 433b93a
So far:
- I have checked kodi.log to see if something gets logged when stutter occurs, but no success.
- I have checked with top to see if there is something eating resources or spiking if stutter occurs, but also no results. Everything seems to be normal
Is it possible that the audio driver still does not get enough CPU time to perform it's task?

Can't believe that

Quote:Any way to check this or other things to check/try?
Any suggestions welcome... thx

Unfortunately I do not have other ideas at the moment

Skywatch · 7th Apr, 2018, 03:26 AM

@Roy Terhaar

What version of pi are you using that had this problem?
How are you getting the audio from the pi? Via the pi audio connector? Via HDMI? Via external DAC (I2S or USB) ?
What else is running on the pi apart from xbian/kodi install?
Are you running the OS from SD only or SD+USB? What SD card are you using? What power supply?
Where is the media stored? On the pi itself or externally?

These would all be useful to know.

Roy Terhaar · 7th Apr, 2018, 09:28 AM

(7th Apr, 2018 03:26 AM)Skywatch Wrote: @Roy Terhaar

What version of pi are you using that had this problem?
How are you getting the audio from the pi? Via the pi audio connector? Via HDMI? Via external DAC (I2S or USB) ?
What else is running on the pi apart from xbian/kodi install?
Are you running the OS from SD only or SD+USB? What SD card are you using? What power supply?
Where is the media stored? On the pi itself or externally?

These would all be useful to know.

Software
XBian version:1.0 (knockout) (kernel: Linux 4.14.32+)
XBMC/Kodi version:17.6-Git:2017-11-18-433b93a
Overclock settings:default

Hardware
Device type and model (e.g. Raspberry Pi Model A/B 256/512 MB, CuBox-i i4Pro, ...):RPI 3
Power supply rating:Original power supply adapter
SD card size and make/type:16Gb
Network (Ethernet or wireless):Kodi using Ethernet; wireless adapter active too on different network
Connected devices (TV, USB, network storage, ...):Yamaha RX-V733, Philips TV, External USB harddisks Seagate and Seagate Backup Plus

Audio is connected via HDMI to the AVR (Yamaha RX-V733) and from there to the TV

Other software running on the pi
-apache2 webserver
-pihole (dnsmasq)
-rsyslogd and fail2ban
-deluged

OS is running from SD card only.
Media to be played is stored on both Seagate harddisks connected directly on the pi's USB ports (both powered by dedicated power supply adapters.), but I always play music from the Seagate Backup Plus drive; most of the files being FLAC.

When nothing is actively running free memory is approx. 470Mb, CPU about 5%.
Once I start playing a music track CPU will be in the region of 10..30% dependent of the track.

***Nachteule*** · (This post was last modified: 7th Apr, 2018 10:13 PM by Nachteule.)

@Roy Terhaar, did you ever tried to play music without those services in the background?

Maybe you've a bandwith problem (all data is going through one USB2 port)

Roy Terhaar · 7th Apr, 2018, 10:47 PM

(7th Apr, 2018 10:12 PM)Nachteule Wrote: @Roy Terhaar, did you ever tried to play music without those services in the background?

Maybe you've a bandwith problem (all data is going through one USB2 port)

Yes I tested shutting those services down one at a time until all were down. It does not seem to have any impact.
The stutter itself is something more like a pause (not the same when you have buffer underrun issues), where the track stops for milliseconds upto few seconds sometimes and then continues from where it stops. So it does not seem that I am 'missing' something from the track that I play.
I also tried playing with VideoPlayer instead of PaPlayer, also this does not make a difference; listening experience reveals same stutter.
VideoPlayer however uses much more CPU; CPU goes higher than 100%(!?) while still playing...

Can the stutter be kernel related?

***Nachteule*** · 8th Apr, 2018, 04:42 AM

(7th Apr, 2018 10:47 PM)Roy Terhaar Wrote:
(7th Apr, 2018 10:12 PM)Nachteule Wrote: @Roy Terhaar, did you ever tried to play music without those services in the background?

Maybe you've a bandwith problem (all data is going through one USB2 port)

Yes I tested shutting those services down one at a time until all were down. It does not seem to have any impact.
The stutter itself is something more like a pause (not the same when you have buffer underrun issues), where the track stops for milliseconds upto few seconds sometimes and then continues from where it stops. So it does not seem that I am 'missing' something from the track that I play.
I also tried playing with VideoPlayer instead of PaPlayer, also this does not make a difference; listening experience reveals same stutter.
VideoPlayer however uses much more CPU; CPU goes higher than 100%(!?) while still playing...

Can the stutter be kernel related?

Did it ever worked without stuttering? Maybe it is a 4.14 kernel issue

Roy Terhaar · 8th Apr, 2018, 10:56 AM

Quote:Did it ever worked without stuttering? Maybe it is a 4.14 kernel issue

Yes it worked without stuttering.
I have been running xbian now for few years on both raspberry pi b+ and raspberry pi 3.
I never had any issues playing audio; also my setup, cables etc have not changed.

I also have minidlna installed; no stuttering issues playing same files with the inbuild client on the AVR receiver. I know this a completely different setup, but at least the hardware seems to be ok and so are the music files.

Not sure what to try next... Huh