Need a way to pass in full alsa device name in the configuration

[sberl]

I various experiments to get my SYBA SD-AUD20101 USB sound card to sample input at 96kHz, I determined that the alsaaudio library is very sensitive to the card name passed in.

Using pyalsaaudio 0.9.0 I could not come up with a value of the "Card" parameter that would work properly at 96kHz.

But if I changed the code to use the "device" parameter instead, it worked with the name "plughw:..." as returned by alsaaudio.pcms(alsaaudio.PCM_CAPTURE).
None of the other names returned by that call would correctly sample at 96kHz.

I've hacked the code a bit to allow the DEVICE parameter instead of the CARD parameter in the .cfg file. The value of this parameter is the full alsa device name as returned by alsaaudio.pcms(alsaaudio.PCM_CAPTURE), and it seems to work correctly now

[ericgibert]

Hi Steve,

Do you recommend to add a new filed under the [Capture] section?

[sberl]

That's what I did, but my code is messy, and I probably broke the "Card" field when I added the "Device" field, and there are a bunch of other changes that need to be cleaned up. So at some point I will be able to send you a clean patch, or a pull request, but not ready yet. Also, I am seeing some very strange behavior. Normally the loop that reads data from alsaaudio in capture_onesec() should finish in about 1 second, but sometimes it takes longer. It seems to get worse the longer the system is running. After a few hours it can take 30 seconds or to capture 1 second. The whole machine gets pretty unresponsive. When it does complete, I get several completing at once. I think that what is happening might be that there are multiple threading.Timers() running at the same time and multiple reads outstanding from different threads on the same alsaaudio.PCM object. But I haven't proven this to myself yet. Still working. This is happening with both the built in sound card, and an external USB card on my Dell desktop machine running a recent Debian Buster. Steve

…

On Tue, Jan 26, 2021 at 11:46 PM ericgibert ***@***.***> wrote: Hi Steve, Do you recommend to add a new filed under the [Capture] section? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#12 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHXLEIXZHR6CVFJ462BZH3S37ADXANCNFSM4WQ53LWQ> .

-- -steve

[sberl]

So after a bit more fooling around with the code, it seems that the memory was leaking and eventually ran out crashing the program. It appears to be related to the tkinter version of the viewer. I switched to text only and it works great, but running the tkinter version will crash in a few hours to a day. Will keep looking and see if I can track down a specific problem/fix. Steve

…

On Wed, Jan 27, 2021 at 8:49 AM Steve Berl ***@***.***> wrote: That's what I did, but my code is messy, and I probably broke the "Card" field when I added the "Device" field, and there are a bunch of other changes that need to be cleaned up. So at some point I will be able to send you a clean patch, or a pull request, but not ready yet. Also, I am seeing some very strange behavior. Normally the loop that reads data from alsaaudio in capture_onesec() should finish in about 1 second, but sometimes it takes longer. It seems to get worse the longer the system is running. After a few hours it can take 30 seconds or to capture 1 second. The whole machine gets pretty unresponsive. When it does complete, I get several completing at once. I think that what is happening might be that there are multiple threading.Timers() running at the same time and multiple reads outstanding from different threads on the same alsaaudio.PCM object. But I haven't proven this to myself yet. Still working. This is happening with both the built in sound card, and an external USB card on my Dell desktop machine running a recent Debian Buster. Steve On Tue, Jan 26, 2021 at 11:46 PM ericgibert ***@***.***> wrote: > Hi Steve, > > Do you recommend to add a new filed under the [Capture] section? > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#12 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAHXLEIXZHR6CVFJ462BZH3S37ADXANCNFSM4WQ53LWQ> > . > -- -steve

-- -steve