FF 45.5.x repeating and/or stuck sound during playback of YouTube videos

[dspiatkowski]

I'm consistently seeing this symptom when attempting to play any sort of YouTube videos.

The content initially begins to load and play...eventually, the time duration here varies, the sound become stuck and continues to repeat in a loop. Basically, the last second or so of sound just repeats. To get out of that loop I can re-load the page, or simply close that particular TAB.

Here is a sample of such a URL:

1) main page which actualy has the embedded video => http://www.itbusiness.ca/news/paypal-and-canada-post-partnership-launches-integrated-payment-and-shipping-solution/91083?utm_source=enews&utm_campaign=itbother&utm_medium=newsletter&scid=200733a2-c26f-d0fd-2d31-4e6003a8d2e8

2) direct YouTube link to the embedded video => https://youtu.be/HZ0-rZeWyfk

I searched the existing Open Ticket queue and found the following: 1) #216 - H264 and AAC broken? 2) #167 - YouTube sometimes does not work quite well for me

...but neither one of these really seem to show the same symptoms I am seeing.

[dryeo]

Which audio mode are you using? Enter SET KAI_AUTOMODE at a cmd prompt to find out (null means UNIAUD). Try the alternate, DART or UNIAUD, eg set KAI_AUTOMODE=DART.

[dspiatkowski]

Hi Dave!

On Fri, 07 Jul 2017 23:28:51 +0000 (UTC), Dave Yeo wrote:

Which audio mode are you using? Enter SET KAI_AUTOMODE at a cmd prompt to find out (null means UNIAUD). Try the alternate, DART or UNIAUD, eg set KAI_AUTOMODE=DART.

I currently have: 'SET KAI_AUTOMODE=DART', will try 'SET KAI_AUTOMODE=UNIAUD' next and will report back...

Thanks! -Dariusz

[dspiatkowski]

Update...

On Fri, 07 Jul 2017 20:21:58 -0400 (EDT), Dariusz Piatkowski wrote:

Hi Dave!

On Fri, 07 Jul 2017 23:28:51 +0000 (UTC), Dave Yeo wrote:

Which audio mode are you using? Enter SET KAI_AUTOMODE at a cmd prompt to find out (null means UNIAUD). Try the alternate, DART or UNIAUD, eg set KAI_AUTOMODE=DART.

I currently have: 'SET KAI_AUTOMODE=DART', will try 'SET KAI_AUTOMODE=UNIAUD' next and will report back...

Well, the UNIAUD change actually took the sound away completely. Not only that, but strangely enough the video playback also appeared to be affected. What happens now is that at most about 5 sec of video plays (without sound) and then the video halts while YouTube displays the 'Experiencing interruptions?' message?

That normaly implies that the ISP or maybe my individual bandwidth is simply not there to stream the video, however I tried this over a full day, multiple times to narrow this down. Currently, as I am typing I completed some tests around 6:30am local time when network usage is historically low.

[dryeo]

On 07/08/17 03:56 AM, Dariusz Piatkowski wrote:

Well, the UNIAUD change actually took the sound away completely.

You probably have to turn up some speakers, easiest is to use PMuniMix (Hobbes) and play around. Here my front speakers need turning up in UNIAUD mode.

[LewisR]

The UNIAUD setting behavior which Dariusz reports jibes with my experience on the ThinkPad T520: video performance is negatively impacted (yes, audio may likely be brought up to level, but the quality is just as jerky). I also saw (probably the cause of the poor audio & video playback performance) considerable CPU load.

In my case, I am on a 150Mbps synchronous fiber line, and can replicate the condition with a variety of sites, as well as local video (which takes broadband completely out of the mix).

This was why we selected DART as the default for ArcaOS, in fact.

Unfortunately, I cannot reproduce. Dariusz, do you see this behavior with 38.8, or only with 45? Have you tried a different/fresh profile? Any extensions? Any plugins?

[ak120]

This behaviour came with the updated NSPR from the RPM repo. It's the same in Seamonkey 2.35 which is rev 38.x. SET KAI_AUTOMODE=DART should work best by not using the Uniaud driver. Otherwise (by using Uniaud) the playback is of lower quality (by measurements) and causes higher system load. OTH SET KAI_AUTOMODE=UNIAUD is broken since ages and produces only silence.

[dspiatkowski]

On Thu, 20 Jul 2017 14:16:58 +0000 (UTC), ak120 wrote:

This behaviour came with the updated NSPR from the RPM repo. It's the same in Seamonkey 2.35 which is rev 38.x. SET KAI_AUTOMODE=DART should work best by not using the Uniaud driver. Otherwise (by using Uniaud) the playback is of lower quality (by measurements) and causes higher system load. OTH SET KAI_AUTOMODE=UNIAUD is broken since ages and produces only silence.

In my case, I am running with 'SET KAI_AUTOMODE=DART' already in place and you are correct, it does give the best behaviour in comparison to UNIAUD. However, the issue I reported is still there.

So are we recognizing some kind of regression in the most recent NSPR you mention?

[LewisR]

Dariusz, I just watched that entire video you referenced at the beginning of this ticket with the latest FF 45.9.0 build. I had no hiccups, no repeating sound, and the video was smooth.

KAI_AUTOMODE=DART

[dspiatkowski]

Hi Lewis,

On Sat, 02 Sep 2017 05:28:22 +0000 (UTC), Lewis Rosenthal wrote:

Dariusz, I just watched that entire video you referenced at the beginning of this ticket with the latest FF 45.9.0 build. I had no hiccups, no repeating sound, and the video was smooth.

KAI_AUTOMODE=DART

Would love to test it out here, where can I get the latest FF 45.9.x release? Last time I saw a reference to a 'fixed' build was regarding yb9p4.7z file...is that still correct?

I did download that release, but it contains a whole bunch of stuff in the directory structure that my current install does not, therefore, not wanting to mess anything up I did not install it.

The current FF 45.x release I am using is identified as: "Build identifier: Mozilla/5.0 (OS/2; Warp 4.5; rv:45.0) Gecko/20100101 Firefox/45.0"

Regarding the issue itself, having tested the other KAI_AUTOMODE mode I went back to SET KAI_AUTOMODE=DART since that was the only way I could get any sound.

Thanks! -Dariusz

[dryeo]

On 09/02/17 06:43 AM, Dariusz Piatkowski wrote:

Would love to test it out here, where can I get the latest FF 45.9.x release? Last time I saw a reference to a 'fixed' build was regarding yb9p4.7z file...is that still correct?

I did download that release, but it contains a whole bunch of stuff in the directory structure that my current install does not, therefore, not wanting to mess anything up I did not install it.

Just move your old program directory out of the way before unzipping the new one.

[dspiatkowski]

Hi Dave,

On Sat, 02 Sep 2017 17:39:52 +0000 (UTC), Dave Yeo wrote:

On 09/02/17 06:43 AM, Dariusz Piatkowski wrote:

Would love to test it out here, where can I get the latest FF 45.9.x release?

Just move your old program directory out of the way before unzipping the new one.

OK, did that but it seems I'm running into an issue after all, most likely another DLL that's different between that build and the working 45.x, here is the error msg:

---

09-02-2017 13:49:40 SYS2070 PID 00c6 TID 0001 Slot 00d3 G:\APPS\TCPIP\FIREFOX_45\FIREFOX.EXE XUL->LIBCX0._exeinfo_open 127

My RPM/YUM installed REL version is 0.5.3, I see a 0.6.0 netlabs-exp out there, is that required for 45.9.x?

Thanks, -Dariusz

[dspiatkowski]

FYI...I updated both the libcx and libc RPM packages, no difference, the same error remains...so I'm guessing there are other DLLs that need updating...

Can anyone provide a list of what's actually required for this latest version of FF 45.x release?

On Sat, 02 Sep 2017 14:26:49 -0400 (EDT), Dariusz Piatkowski wrote:

Hi Dave,

On Sat, 02 Sep 2017 17:39:52 +0000 (UTC), Dave Yeo wrote:

On 09/02/17 06:43 AM, Dariusz Piatkowski wrote:

Would love to test it out here, where can I get the latest FF 45.9.x release?

Just move your old program directory out of the way before unzipping the new one.

OK, did that but it seems I'm running into an issue after all, most likely another DLL that's different between that build and the working 45.x, here is the error msg:

---

09-02-2017 13:49:40 SYS2070 PID 00c6 TID 0001 Slot 00d3 G:\APPS\TCPIP\FIREFOX_45\FIREFOX.EXE XUL->LIBCX0._exeinfo_open 127

My RPM/YUM installed REL version is 0.5.3, I see a 0.6.0 netlabs-exp out there, is that required for 45.9.x?

Thanks, -Dariusz

[dryeo]

On 09/02/17 11:26 AM, Dariusz Piatkowski wrote:

09-02-2017 13:49:40 SYS2070 PID 00c6 TID 0001 Slot 00d3 G:\APPS\TCPIP\FIREFOX_45\FIREFOX.EXE XUL->LIBCX0._exeinfo_open 127

You need a newer libcx. There's one in the experimental repository that also needs the updated libc that is there or I have one on my SeaMonkey bitbucket page.

[LewisR]

Hi, Dariusz...

Reboot.

This is necessary to get the updated libcx into memory. You've still got the old one stuck until the restart.

Indeed, you should be good to go with that build.

PM coming later.

[LewisR]

Dave, libcx 0.60 from exp should be all that's required.

[dspiatkowski]

Lewis, Dave and FF Team,

Indeed, that is all that was required, a re-boot. I should have cought that actually since some time ago this was the exact same issue I had ran into...took a good day of scratching my head to figure this out back then.

OK, I've got FF 45.9.x up and running here. So back to the repeating audio on YouTube. I just went through about 10 different videos, each between 5-10 mins in length. The audio problem is still there, however, I believe it does not happen as often as it previously did. No way to measure this however, so at best it's a qualitative assessment.

Lewis, Specifically that video I listed in the ticket plays nice & clean here as well. So maybe it is the longer videos that somehow cause the audio problem. I will pay attention to this and will try to log some better data to investigate with.

On a separate, non-FF note, would it be possible to enhance ANPM to be aware of specific DLLs which absolutely do require a system re-boot? I am thinking that even if it meant an exception list would be maintained and stored in an INI file, ANPM during an up/down-grade of such a DLL could be enhanced to show a pop-up msg box notifying the user that a re-boot was absolutely required. In the future that approach might avoid the occurence of reporting such issues as code/package problems, since clearly they are not.

Thanks, -Dariusz

On Sat, 02 Sep 2017 19:19:53 +0000 (UTC), Lewis Rosenthal wrote:

Hi, Dariusz...

Reboot.

This is necessary to get the updated libcx into memory. You've still got the old one stuck until the restart.

Indeed, you should be good to go with that build.

[LewisR]

Hi, Dariusz...

On a separate, non-FF note, would it be possible to enhance ANPM to be aware of specific DLLs which absolutely do require a system re-boot?

Already in the works, and for those who prefer the command line, this functionality will be going into yum directly. Thus, when installing something considered to be a critical component, ANPM will display a panel advising that the system must be rebooted to continue. Upon restarting the system and re-launching ANPM, the update/install operation will complete. This is in alpha testing right now.

Coming soon to an Arca Noae website near you. ;-)

Meanwhile, if you have some more examples of repeating and/or stuck audio, please post them. FWIW, I'm currently on a 150Mbps synchronous fiber line (all of my testing for this is done wired, so Wi-Fi bandwidth limitations don't apply, either).

Cheers

[SilvanScherrer]

anyone tested this with the latest uniaud installed? As we believe it's more a uniaud issue than a FireFox issue.

[dspiatkowski]

Hi Silvan,

On Wed, 11 Apr 2018 09:20:33 -0700 Silvan Scherrer wrote:

anyone tested this with the latest uniaud installed? As we believe it's more a uniaud issue than a FireFox issue.

Let me find the latest uniaud drivers (AN ftp somewhere I presume?), I'll install them and re-test. Gime me a couple of days please...

Thanks,

• Dariusz

[dmik]

@dspiatkowski Netlabs I believe (http://trac.netlabs.org/uniaud/wiki).

[SilvanScherrer]

yes netlabs. http://trac.netlabs.org/uniaud/wiki#DownloadingBinaryDistributions has the links

[dspiatkowski]

OK, got some results you guys!

Installed the latest version available (Uniaud-20180117.exe), that took me from:

1) PREVIOUS UNIAUD32 = 1.09.26 UNIAUD16 = 1.09.06

2) NEW UNIAUD32 = 2.02.04 UNIAUD16 = 1.09.7

Going back to the Youtube link I originaly provided I am now able to play back the video w/o any audio hesitation. Keep in mind, I can only do this while using the h264ify add-on, else by default the video simply does not play. This I believe is a known and separate issue though.

So, to prove this out further off I went hitting a bunch of additional video feeds, many at 1080 resolution, all played fine, no problems.

[SilvanScherrer]

so this issue is/was a uniaud issue. We expected that.

[dspiatkowski]

Silvan,

On Fri, 13 Apr 2018 19:26:34 +0000 (UTC) Silvan Scherrer wrote:

so this issue is/was a uniaud issue. We expected that.

Well, I can only say the following: at the time the issue was reported by me Firefox was the only application showing this symptom. The remaining apps which I use, such as: VLC, SMPlayer, mplayer, or more audio centric ones, such as pm123 for example did not show these symptoms.

Therefore, I would wager a guess that Firefox somehow exposed a weakness within the UniAud driver, and it looks like the changes between my old version and the current version addressed whatever that weakness may have been.

Unless someone else reports a continuing issue here I would say I am happy with the results of the UniAud driver update and therefore propose that we close the ticket.