Re: [Alsa-user] USB Synchronization w/ALSA via g_audio
Rob wrote: > I am capturing data from my microphone, and transmitting it via > pcm_write() to the USB gadget card, and arecording on the USB host. > If I query the buffer, I begin to see a creeping fill on the device > side buffers, such that after a few hours of constant streaming, the > buffer is filled, and my pcm_write is returning "we only wrote SOME > of your data". The ALSA API was designed for 'normal' sound cards where only the hardware itself can control the sample clock. This means that the USB audio gadget does not give you control over its clock, and that samples are moved synchronously with the USB bus clock. You'd have to measure the clock difference, and dynamically resample the stream. (Zita-ajbridge does something like this.) Alternatively, it might be possible to extend the audio gadget driver to add a mechanism to slightly adjust the sample rate, relative to the bus clock. Regards, Clemens -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] Get triggered when the device opens
Hello, just to finish this thread, a colleague of mine put me on the right track: timers. If you look at the alsa-lib timer example http://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2timer_8c-example.html , you see the timer interface being used to register on master timer ticks. The read loop simply waits on poll. Actually, timer work on a variety of events, see http://www.alsa-project.org/alsa-doc/alsa-lib/group___timer.html , enum snd_timer_event_t . To register on specific events, you create a filter mask of your events ( 1 << event1 || 1 << event2 || ... ) and set it to your timer parameters with snd_timer_params_set_filter . In read loop of the timer example, you just need to use snd_timer_tread_t instead of snd_timer_read_t . In my case, I registered on the timer events SND_TIMER_EVENT_MSTART and SND_TIMER_EVENT_MSTOP and it works as expected. Regards, Thomas From: Frank Thomas Sent: 04 June 2018 08:53:57 To: alsa-user@lists.sourceforge.net Subject: Get triggered when the device opens Hello, I'd like to apologise beforehand if I have not read enough documentation and/or source code to be posting here. Please do not hesitate to tell me to RTFM ☺ My application needs to get triggered when a mechanism any application is opening or closing a certain list of ALSA devices. It seems that ALSA hooks would be a way to do it. AFAIK I can only use a hook to trigger a function a in a pcm control plugins with certain arguments. I would need implement a control plugin that notifies my application for me and use a hook to trigger the trigger ☺ Is there another way, e.g. with the ALSA API, to get triggered on such events? Thanks in advance. Regards, Thomas Frank -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] USB Synchronization w/ALSA via g_audio
Hi Chris, My goal is a low latency USB microphone that's always on; similar to an intercom system. I am capturing data from my microphone, and transmitting it via pcm_write() to the USB gadget card, and arecording on the USB host. If I query the buffer, I begin to see a creeping fill on the device side buffers, such that after a few hours of constant streaming, the buffer is filled, and my pcm_write is returning "we only wrote SOME of your data". As this happens, I start to notice more and more latency between my device's capture and the host's playback, as I eventually have a whole buffer's worth of "old" audio I'm queuing "now's audio" data behind. If I modify the UAC driver to provide a larger buffer size, my pcm_write of "not a full buffer" takes longer to happen, but when it does, my latency has gone from unnoticeable to several seconds. I figured (and may very well be wrong), that this was due to my device clocks sending buffers at a rate *slightly* faster than the USB is able to sink it to the host. Could this be something else? Thanks, Rob On Thu, Jul 12, 2018 at 8:13 PM, chris hermansen wrote: > Rob and list, > > On Thu, Jul 12, 2018, 19:27 Rob wrote: > >> Hi all, >> >> I'm reading about the feedback mechanism for USB audio. I'm trying to see >> if I can implement asynchronous mode. >> > > What makes you think asynchronous mode isn't already implemented? > > Chris Hermansen > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
