Re: USB audio garbled over time

I solved my issue. I started having this issue on Linux too, again very
randomly. Tried a different USB port and everything works. Whatever is
happening with the controller on these ports, it doesn't play nicely
with audio hardware but the other one does. Pretty sure I went from USB
2.0 to USB 3.0, or 3.1 or whatever number of the 3 or 4 different
versions I wound up with on this board.

Courtney


On 7/1/22 11:09, Courtney wrote:
> Sure enough, looks like it pauses.
>
> Before:
>
> name=uaudio0
> mode=play,record
> pause=0
> active=1
> nblks=16
> blksz=480
> rate=48000
> encoding=s16le
> play.channels=2
> play.bytes=839040
> play.errors=0
> record.channels=2
> record.bytes=839040
> record.errors=0
>
> After:
>
> name=uaudio0
> mode=play,record
> pause=0
> active=1
> nblks=16
> blksz=480
> rate=48000
> encoding=s16le
> play.channels=2
> play.bytes=1827840
> play.errors=0
> record.channels=2
> record.bytes=1827840
> record.errors=0
>
> How do you unpause it then?
>
>
> Courtney
>
> On 6/30/22 21:54, Alexandre Ratchov wrote:
>> On Thu, Jun 30, 2022 at 03:11:18PM -0700, Courtney wrote:
>>> Hello everyone,
>>>
>>> I am running OpenBSD -current branch right now. I have a FiiO E10k
>>> plugged
>>> into my board. Here is the part of the dmesg when it is connected
>>>
>>> Jun 30 15:02:48 towerDefense /bsd: uaudio0 at uhub0 port 14
>>> configuration 1
>>> interface 2 "FiiO DigiHug USB Audio" rev 1.10/0.01 addr 6
>>> Jun 30 15:02:48 towerDefense /bsd: uaudio0: class v1, full-speed, sync,
>>> channels: 2 play, 2 rec, 3 ctls
>>> Jun 30 15:02:48 towerDefense /bsd: audio1 at uaudio0
>>>
>>> I have been trying to pinpoint an issue where after a time of being
>>> away
>>> from my computer,
>>> when I come back my audio isn't behaving. I'm not an audio guy so I
>>> will
>>> probably mess
>>> up some terms, sorry. The pitch sounds right but the audio has a lot of
>>> static in it. Normally
>>> this happens after I walk away from my computer and come back maybe
>>> an hour
>>> later. It
>>> doesn't go into any sleep state, only power efficiency mode that the
>>> monitors handle on their
>>> own. An rcctl restart sndiod doesn't solve the issue, I have to
>>> physically
>>> unplug and plug it,
>>> then run rcctl restart sndiod and all is back to normal. Nothing
>>> appears in
>>> the logs for me
>>> to report. What can I look at when I encounter this again to see
>>> what is
>>> being changed
>>> (if anything)? Or, maybe my hardware is just progressively giving up
>>> the
>>> ghost? This has been
>>> happening for a while now.
>> When you walk away is it playing? you can run:
>>
>>     audioctl -f /dev/audioctl1
>>
>> to check device state before and after the walk (empty "mode" means
>> it's closed, "pause=0" means it's playing or recording)