Re: Bookworm 20230504 - sound state is muted on power on with qemu 7.2 arm64
On May 5, 2023, at 07:56, Jason White <jason@jasonjgw.net> wrote:
>
> Unfortunately, I don't have suggestions to offer on this specific issue. However, given that virtualization seems to be an important causal factor in both this problem and in your Speakup problems, at some point the question is whether you can reasonably reorganize your computing environment so that you aren't running Linux on a virtual machine. At least, to the extent that you really have to virtualize it, can you access it via ssh from the host operating system, and ensure that the host gives you the accessibility you need for the ssh session?
The reason for the virtualization is the screen reader. The host systems screenreader does not perform adequately in a terminal.. I may have communicated this previously, but I am willing to change the way I access a console. I'd prefer that I can access a console from the same machine that I also use for other tasks that are not in a terminal. I will give another shot at fenrir on macos.
This is not some new configuration. I've been running espeakup on a virtual machine, as my terminal accessibility, for more than a decade on macos.
I figured there would be growing pains, moving to a different host architecture and a new virtualization engine. What I've found is that the overall performance of qemu on macos is spectacular, mind blowingly spectacular. I almost wonder if the performance is so good that it's the cause of some timing problems. I don't have any other modern high performance hardware to try espeakup on to see if that is the issue.
I know that a few of these qemu issue can be worked out, and for the most part they have been. I mostly have a system that works. I'm also quite aware of when the speech will stop and I have a procedure in place for handling it.
That said, I could really enjoy some tighter integration of terminal use with other applications, things like copy and paste, as well as data detection for things like phone numbers and URIs.
I'll keep banging on this from multiple angles.
>
> I have two machines here running different operating systems, neither with virtual machines installed. I could, of course, take that path, but I've so far resisted on the basis that the virtualization introduces additional sources of unreliability that I don't need in addition to everything else that can and does go wrong.
One of the reasons why I purchased a mac is that there is accessibility in the UEFI. I have mentioned on this list before that I like to buy machines with a baseboard management controller, as it gives us accessibility in the early boot stage. Virtualization does that too.
>
> In your case, would it be more feasible to solve your virtualization-related problems, or would it be better to make larger changes so that you don't need to run screen readers on virtualized guests?
I have other machines with speakup running here also, but I tend not to use them, as they aren't integrated in to my workflow. My real concern is if speakup is going to be the terminal screenreader I use going forward?
I really appreciate the discussion.
Thank you,
--FC
>
> On 4/5/23 09:28, Frank Carmickle wrote:
>> Greetings Debian accessibility folk,
>>
>> I'm finding that on power on the sound card is muted. It appears that alsactl restore is being run, and even if I run it by hand it doesn't unmute the card. It appears that the card is in a muted state even though alsa thinks that it is not. Toggling the mute state on and off causes the audio to work. If I reboot the machine the sound comes up working. It's particularly an issue with the power on state. I'm running qemu 7.2 arm64.
>>
>> Has anyone sorted this trouble out for themselves?
>>
>> Thanks much.
>> --FC
>>
>
Reply to: