Chromebook/linux playback issue
MS 4.2. I5 8 gig
This week upgrade for Linux container. Upgrade went fine. Afterwards playback had a tick sounding right with the notes. Or at least most notes. Occasionally one note sounds fine, but then the ticks follow. Not 'that' noticeable with larger group of instruments, but very much so with one or two playing. Metronome is not on, made sure. Never use it. Seems to also be extra bit of reverb. Reverb is also off for all instruments. The score is the same as before the upgrade.
Question is anyone else who did the upgrade experiencing the same issue or is this just another of the oddities I experience? It is not just with the one score as I did another test score with same issue.
If you have not done the upgrade yet, I would think before doing it. If you need more storage space with your chromebook it might be worthwhile. After I did update/upgrade for my system I gained an additional 400+ megs with unneeded items for removal.
Any thoughts? Help!
Comments
I completed the same update with no trouble at all, but every audio device is different. Did you already follow the procedure for ensuring that your sample rate is set to 44.1 kHz? If not, that's probably the issue right there.
To check the current the sample rate, you need to run:
pw-metadata -n settings 0 clock
Look for the values of "clock.rate" and "clock.force-rate". My guess is you'll find the former 48000 and the latter 0. You want both to be 44100. So you'd run:
pw-metadata -n settings 0 clock.rate 44100
and also
pw-metadata -n settings 0 clock.force-rate 44100
Actually, the first one might be unnecessary, probably depends on the system.
You need to run those commands after every reboot, so ideally you'd place them in a file that gets executed at Linux startup. Unfortunately I haven't experimented with Debian 12 enough to know for sure how that might work. But presumably placing them at the end of the ".profile" file would work.
If pw-metadata is not already installed, you'll get an error running any of those commands. So you'd to install PipeWire first with
sudo apt-get install pipewire
Unfortuantely, again, I'm not positive if there are any other steps needed on Debian 12. I installed this in Debian 11 but according to the documentation, things have changed, it just isn't clear to me how.
In reply to I completed the same update… by Marc Sabatella
Probably a good thought, but no help for me.
Pw- meta etc. 'Command not found.
Sudo apt- etc. 'Pipewire is set to manually install.
So I got nowhere fast! Thanks for the thought. This seems to be my luck with this system. Anything I tried to find was more standard linux separate sound card.... and waaay above my head.
Pipewire did say latest version for deb12.
In reply to Probably a good thought, but… by R. L. F.
If you run the pipewire install command again then take a screenshot or otherwise grab the output and attach it here, I can see if I can figure anything out. I definitely want to make sure I know what to tell Chromebook users regarding how to get their audio working better, so posting the full output would help you, me, and everyone else.
In reply to If you run the pipewire… by Marc Sabatella
I shall try to send a screenshot....as soon as I figure out how to do it, again.
For fun I tried loading MU 4.2 from the apps launch window. It was very tiny fonts again(thanks for QT_SCALE) seemed even smaller than what I remembered for 4. As we both surmised, it did not effect the playback. Still bad.
As I think about this further I have a problem with freq. rate and sample rate being the problem. It Has been decades since I was really involved in audio, specifically. But as I remember when the two rates were different the playback would simply default to the lower of the two and just play. No extra sounds or other issues involved. I know mp3 files work pretty much that way. So I am very confused as to why it would be different with MU4. Especially since it was playing fine the moment before the upgrade and not after. And still plays fine withMU3. I do not see how/why an upgrade to the container would effect either of those functions. Or even need to. And besides the extra tick with each note, it still sounds like reverb is on for each note and at times I am sure the changes of tempo throughout the movement are not Always happening. But that is a hard one, other than significant changes are still obvious.
I will try to get the screenshot as soon as I can. I will be very interested in what is discovered. Thanks!
In reply to If you run the pipewire… by Marc Sabatella
Well....going to try. This is screenshot of running install of pipe wire.
says it is loaded! Hope so.
In reply to Well....going to try. This… by R. L. F.
Looks good indeed. So now try the pw-metadata commands again.
In reply to I completed the same update… by Marc Sabatella
I am amazed that you were able to do something from your end, only.
Half-step forward, though.
Pw-metadata etc. returned....Found "settings" Metadata 32.
Pw-metadata 32 returned....Found "default" Metadata 36
Pw-metadata 32 settings 0 clock returned....Found "default" Metadata 36 set property: id:32 key:settings value:0 type:clock
Meaningless to me, but unfortunately no clock rate settings appeared. Hope this might tell You something!
In reply to I am amazed that you were… by R. L. F.
It seems you must have mistyped the command - I never wrote anything about typing "32". But also, I made a mistake in the first command. Leave out the "clock". It should look something like this:
marcsabatella@penguin:~$ pw-metadata -n settings 0
Found "settings" metadata 32
update: id:0 key:'log.level' value:'2' type:''
update: id:0 key:'clock.rate' value:'48000' type:''
update: id:0 key:'clock.allowed-rates' value:'[ 48000 ]' type:''
update: id:0 key:'clock.quantum' value:'1024' type:''
update: id:0 key:'clock.min-quantum' value:'1024' type:''
update: id:0 key:'clock.max-quantum' value:'2048' type:''
update: id:0 key:'clock.force-quantum' value:'0' type:''
update: id:0 key:'clock.force-rate' value:'44100' type:''
Except you probably will see different values for "clock.rate" and "clock.force-rate".
The next two commands need to be typed as shown, no improvising with "32" (well, there probably (is a way to ue that number, I just don't know it). These commands should do the following:
marcsabatella@penguin:~$ pw-metadata -n settings 0 clock.rate 44100
Found "settings" metadata 32
set property: id:0 key:clock.rate value:44100 type:(null)
and
marcsabatella@penguin:~$ pw-metadata -n settings 0 clock.force-rate 44100
Found "settings" metadata 32
set property: id:0 key:clock.force-rate value:44100 type:(null)
At that point you should immediately notice an improvement in playback. And by immediately, I mean, even if you're actually currently listening to playing - no need to stop and restart playback, quit and relaunch MuseScore, reboot, or anything.
But that last command - the one with the "force-rate" - will need to be run after every reboot.
In reply to It seems you must have… by Marc Sabatella
Yes! It is working again! Thanks!
No, I entered everything correctly. You also got the '32'. I just thought I would see if it would give any further response. Just guessing. I think you will read 'I entered' on all of those later statements with 32 & 36.
Thanks again Marc. I was about to start working in MU3.2 to hear my work, then open in 4.2 to finish the look. Saves a looot of extra work.
Guess I will just be adding the 'force-rate ' command before QT_SCALE from now on. Any idea why that suddenly became a problem after the container upgrade? Seems very odd. Thanks again for your efforts. Hope this helps anyone else who might have the problem.
In reply to Yes! It is working again!… by R. L. F.
Glad it worked! For me, I always needed to set the sample rate to 44100 to avoid problems, on both of my Chromebooks. But each system is different in terms of its internal hardware and how it interacts with the operating system. Could be Debian 11 on your system was already using 44100 as the default given your specific hardware and there it was working, but for Debian 12 they decided to always use 48000. Or it could be 48000 worked better in Debian 11 for your specific hardware.
In reply to Glad it worked! For me, I… by Marc Sabatella
Marc
I believe I was/am on 'buster' which is Deb 12. Either way I do not think there was any change with the 'container' upgrade. So it was same version after as just moments before. For me just very confusing, but thanks again for your help!! I had finished the movement and piece I was working on and it Will be pleasant to hear it playing correctly.
All your efforts are Much Appreciated.
In reply to Marc I believe I was/am on … by R. L. F.
The container upgrade is the change from Debian 11 (or whatever you had before) to 12.
In reply to The container upgrade is the… by Marc Sabatella
I had obviously fallen behind on names and numbers. Odd that last upgrade said numbers and names.
Thanks for the qualification.
Aside...I did look at your video/tip about title page. It was what I assumed, though with some helpful location references for modifications and set-up in the page. Helpful.
In reply to It seems you must have… by Marc Sabatella
Marc
Update. You were right something needs to be run after shutdown. I ran force-rate 44100, but still not working. Then did clk settings 0 and clk rate was 48, force was 44. Reset clk rate to 44 and working. So actually I may need to run both.
Then I started to wonder? Is there any reason force-rate can not be 48? Have you run into this? If so then I probably will only need one reset, as you suggested.
In reply to Marc Update. You were right… by R. L. F.
Update 2
You most likely knew this, but playback does not work(for me) at 48 kHz. I have to change both settings to 44100. I just mention this because you earlier implied you wanted to understand in case someone else comes upon this or similar issue.