Re: Can't seem to change index of audio controller

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Jeremy,

So, I'm doing some testing with language models for the purposes of troubleshooting things like this. I ran your query through the latest release of the `llava:7b-v1.6-mistral-q4_0` model and this is what it generated:

-----------------------------------------------------------------------------------------------------------------------------------------------------------
Thank you for sharing your experience with the audio device on your new notebook. Based on the information provided, 
it seems that you are using the `snd-soc-ps-mach` kernel module for your 
Advanced Micro Devices, Inc. [AMD] ACPI device, and you want to assign it a higher index number so that it is not assigned the default index of 0.

The `index` option you mentioned is not a valid option for the `snd-soc-ps-mach` kernel module. 

However, you can use the `snd-soc-acp63` module, which is specifically designed for Advanced Micro Devices, Inc. [AMD] ACPI devices. 

This module should support the `snd-soc-acp63` kernel module and should work with your device.

To load the `snd-soc-acp63` module, you can add the following line to your `/etc/modprobe.d/` file:

```
options snd-soc-acp63 index=12
```
This should assign the `snd-soc-acp63` module a higher index number of 12.

As for your question about USB audio devices, it is possible to discern between different USB audio devices based on their vendor and product IDs. 

In your case, the USB audio device has a vendor ID of 1d6b and a product ID of 0003. You can use these IDs to load the correct kernel module for each device.

For example, if you have multiple USB audio devices, you can use the following command to load the correct kernel module for each device:

```
sudo modprobe snd-usb-audio vendor=1d6b product=0003
```

This will load the `snd-usb-audio` kernel module for the USB audio device with the vendor ID of 1d6b and the product ID of 0003.

Regarding your concern about USB frames/period, it is not advisable to use a period size lower than 64 frames. 
This can cause issues with your system's stability and performance. If you need to use a lower period size, 
you can try adjusting the buffer sizes or using a different USB audio device that is more compatible with your system.

I hope this information helps you with your audio device and USB issues. If you have any further questions or concerns, please don't hesitate to ask.

Best regards,
Soundbot

-------------------------------

I can confirm the information regarding the scp63 module up to a point, you can see the options for indexing starting on line 253 here: [ https://elixir.bootlin.com/linux/latest/source/sound/soc/amd/ps/acp63.h ]. I wasn't able to find such similar notation for the mach module.

I'd appreciate your testing the accuracy of this generated information. This was generated using a prompt designed to assist with Linux audio production and troubleshooting without using a supplemental knowledge-base or additional training. So I'm delightfully surprised that the response it generated just from your initial query seems immediately actionable, if not very close to it, without the need for additional steps or resources. Even your reference to the Pink Sardine didn't interfere with the response as it seems well placed within the context, which means to design applications specific to this domain, far less work needs to be done.  If so, that would be a wonderful thing. Thank you for your time and valuable input.

On Wed, Jan 31, 2024 at 6:16 AM Jeremy Jongepier <jeremy@xxxxxxxxxxxxxx> wrote:
Hello David,

On 30-01-2024 15:47, David Kastrup wrote:
> Stupid question: have you tried 48 frames/period already?  That fits
> better with the timing interrupts.  For particular cards, even 24 frames
> may work while 64 frames gives trouble.

Yes, tried 48/2, 32/3, 24/4, 12/8, etc. All choppy and below 32 playback
also slowed down. With implicit feedback enabled playback is fine at 32.
If I go lower than 2ms systemic latency everything becomes chopped again
and Ardour slouches through the session.

>> I've resolved this by passing implicit_fb=1 to the snd-usb-audio
>> driver. I can now go as low as 1ms systemic latency without choppy
>> audio or the logs filling up.
>
> What does it do?

Best explanation I could find so fast:
https://developer.apple.com/library/archive/technotes/tn2274/_index.html#//apple_ref/doc/uid/DTS40010116-CH1-TNTAG4_3

And the announcement of its implementation:
https://patchwork.kernel.org/project/alsa-devel/patch/20201123085347.19667-40-tiwai@xxxxxxx/

Since this is all very technical I can't really get my head around it
myself and come up with a simpler explanation :(

Best,

Jeremy
_______________________________________________
Linux-audio-user mailing list -- linux-audio-user@xxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to linux-audio-user-leave@xxxxxxxxxxxxxxxxxxxx
_______________________________________________
Linux-audio-user mailing list -- linux-audio-user@xxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to linux-audio-user-leave@xxxxxxxxxxxxxxxxxxxx

[Index of Archives]     [Linux Sound]     [ALSA Users]     [Pulse Audio]     [ALSA Devel]     [Sox Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux