August 2013 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] Ambiguous DAPM widget names and DPCM
by Daniel Mack 21 Mar '14

21 Mar '14

Hi Mark, Hi Liam, I spent some hours reverse-engineering the DPCM code, and I plan to prepare a patch to add some documentation once I've assembled a fully working setup. However, I have a general question regarding DAPM widget names. DPCM uses DAPM widgets and routes in order to determine the FE <-> BE connections at runtime. The problem with this is that widget names are very ambiguous, as the automatically created widgets for DAIs are named after their stream_name properties, which contain "Playback" or "Capture" for all components in my case. Hence, the code which walks the connections (snd_soc_dapm_dai_get_connected_widgets()) will most likely match the wrong one (which has empty sound/sink lists), which results in a failure like this: [ 16.606268] fe: ASoC: fe no valid playback route I hacked the names of all components so they are unique, but even then, the problem is that snd_soc_dapm_new_dai_widgets() is called twice for the CPU DAI, once from soc_probe_platform(), and later from soc_probe_link_dais(), and both calls would create DAPM widgets with identical names, resulting in the same problem as described above. I don't know how to handle this, but I believe that nobody was really hit by this issue yet, as DPCM doesn't seem to be used widely, at least not by any machine code in mainline. One idea would be to change the automatically generated names of DAI widgets in order to make them unique, or re-factor the lookup routines. Any opinion on that? Do I miss a general consideration here? With more hacks in place, the setup somehow succeeds, but when the stream is opened, we'll hit a BUG() in sound/core/pcm_memory.c, because the FE device's DMA type is undefined. But that's another topic I'll address later. Thanks, Daniel

5 9

Re: [alsa-devel] snd-usb: "delay: estimated 0, actual 352"
by Takashi Iwai 08 Jan '14

08 Jan '14

At Thu, 6 Sep 2012 15:17:58 +0200, Markus Trippelsdorf wrote: > > On 2012.09.06 at 15:08 +0200, Takashi Iwai wrote: > > At Thu, 6 Sep 2012 11:43:48 +0200, > > Markus Trippelsdorf wrote: > > > > > > On 2012.09.06 at 10:21 +0200, Takashi Iwai wrote: > > > > At Thu, 06 Sep 2012 09:35:26 +0200, > > > > Takashi Iwai wrote: > > > > > > > > In short, a patch like below may fix the issue (note: completely > > > > untested!) > > > > > > No it doesn't, unfortunately... > > > > OK, I start tracking down the problem a bit more deeply now. > > > > The issue happens when the first two URBs are passed to > > retire_playback_urb(). These are URBs filled before start_endpoints() > > are set, so they contain actually zero size. Even though these are > > a sort of dummy packets, the driver still tries to check with the > > queued delay account, and gives bogus errors. > > > > So, essentially the messages are harmless and nothing to worry too > > much, but surely it doesn't look sexy. > > > > The patch below should fix the problem. Please give it a try. > > Yes, your patch finally fixes the problem. > Thank you Takashi-san. Thanks for your quick test! If Daniel has no objection with that patch, I'm going to merge it. Takashi

3 2

[alsa-devel] how to create alsa nodes?
by loody 12 Dec '13

12 Dec '13

Dear all: In destop x86 system, the udev will automatically create the nodes in snd directory, such as pcmC0D0c, pcmC0D1c, etc. I try to let the usb sound device work on mips platform, but I have no idea what is the proper way to create these nodes. Should I 1. create them one by one by hand from copying the attributes in my PC (if I have 2 or more usb sound devices, I have to first plug them in pc and monitor the nodes) 2. smarter way to do so? -- Regards, miloody

7 19

[alsa-devel] alsa/asoundlib.h file not found
by Appalayagari Sreedhar 05 Dec '13

05 Dec '13

Hi, I have integrated the codec driver and the kernel log shows the sound card is detected. now i want to test the codec. i tried the sample test code for capture and playback. i am getting a compilation errors due to the asoundlib.h. please find the error log for my application. main.c:2:23: error: asoundlib.h: No such file or directory main.c: In function 'main': main.c:7: error: 'snd_pcm_t' undeclared (first use in this function) main.c:7: error: (Each undeclared identifier is reported only once main.c:7: error: for each function it appears in.) main.c:7: error: 'pcm_handle' undeclared (first use in this function) main.c:10: error: 'snd_pcm_stream_t' undeclared (first use in this function) main.c:10: error: expected ';' before 'stream' main.c:15: error: 'snd_pcm_hw_params_t' undeclared (first use in this function) main.c:15: error: 'hwparams' undeclared (first use in this function) main.c:22: warning: 'return' with a value, in function returning void main.c:34: error: 'snd_pcm_uframes_t' undeclared (first use in this function) main.c:34: error: expected ';' before 'periodsize' main.c:46: error: 'SND_PCM_ACCESS_RW_INTERLEAVED' undeclared (first use in this function) main.c:48: warning: 'return' with a value, in function returning void main.c:52: error: 'SND_PCM_FORMAT_S16_LE' undeclared (first use in this function) main.c:54: warning: 'return' with a value, in function returning void main.c:62: warning: 'return' with a value, in function returning void main.c:65:19: warning: missing terminating " character main.c:65: error: missing terminating " character main.c:66: error: expected expression before '==' token main.c:66: error: stray '\' in program main.c:66:31: warning: missing terminating " character main.c:66: error: missing terminating " character main.c:67: error: expected ';' before '}' token main.c:72: warning: 'return' with a value, in function returning void main.c:78: warning: 'return' with a value, in function returning void main.c:86: error: 'periodsize' undeclared (first use in this function) main.c:88: warning: 'return' with a value, in function returning void main.c:99: warning: 'return' with a value, in function returning void main.c:112: warning: incompatible implicit declaration of built-in function 'malloc' main.c:115: error: 'num_frames' undeclared (first use in this function) main.c:5: warning: return type of 'main' is not 'int' please suggest what needs to be done to resolve this issue asap. Thank you, Sreedhar.

5 4

[alsa-devel] Questions about virtual ALSA driver (dummy), PortAudio and full-duplex drops
by Smilen Dimitrov 21 Oct '13

21 Oct '13

Hi list(s), Apologies in advance for the longish exposition - however, I have bumped into a problem with ALSA driver development, which raised some questions that I cannot really understand at the moment. I find it especially frustrating that I cannot formulate a simple question, but instead I have to resort to test code, captures and plots, to discuss my (mis)conceptions through those - so I hope at least someone will bear with this wall of text (some 23KB plaintext), and I'll be able to get some help with this. I originally started working on a 16-bit, 44.1 kHz stereo ALSA driver for a device; and came to a point where I could achieve (what I thought was) full-duplex by running `arecord` and `aplay`, in separate shells, without any problems. However, if I tried to do the same from `audacity` - that is, have "record" running, while another track plays on the same card, with "Audacity Preferences/Recording/Overdub: Play other tracks while recording new one" enabled - then I'd experience some strange drops in the capture, which were not reported by any debug messages, even after I rebuilt and used PortAudio with debug messages on (my eventual goal is to have this experiment running in Audacity without drops). (Therefore CC to audacity-devel, since I first started looking for "audacity full duplex drops" and couldn't find much; and CC to portaudio since some of my questions depend on correct understanding of PortAudio). Anyways, I think I managed to reconstruct the drop problem I get (with my device driver and `audacity`), by using a modified command line program from the tests in the PortAudio distribution, and a modified `dummy` driver from the ALSA distribution. The complete code and test scripts are available in this directory: http://sdaaubckp.sourceforge.net/post/alsa-patest-duplex/ I ran this on Ubuntu 11.04 Natty, Linux 2.6.38 and corresponding ALSA 1.0.24.2, audacity-1.3.13, PortAudio V19 - more about my machine and environment setup is in the Readme: http://sdaaubckp.sourceforge.net/post/alsa-patest-duplex/Readme In that directory there is a script, `run-alsa-pa-tests.sh`; which compiles: the ALSA driver from `dummy-2.6.32-patest.c`; and the PortAudio program from `patest_duplex_wire.c`; with different compile-time defines - and then runs the program, obtaining verbose logs (some timestamped through `ftrace`), which end up as .csv files. The .csv files are finally plotted in the time domain using a gnuplot script, `traceLogGraph.gp`, through a batch script `batch_traceLogFile.sh`. Note you may have to change some hardcoded values in the source codes, if you want to run this collection on your machine - see the Readme for more. The file `captures01-04.tar.gz` contains complete logs from four runs of `run-alsa-pa-tests.sh` (NB: +70MB expanded), with respective `traceLogGraph.gp` gnuplot scripts that allow for reconstruction of all .png images; while the `captures_0*/` directories contain only some .pngs (those that will be referenced here). Back to the problem: once I started working with `patest_duplex_wire.c`, I realised there are actually two ways to implement "full-duplex", understood simply as "playback and record at the same time", in PortAudio: * By using two separate `PaStream*`s, with two `Pa_OpenStream`s and `Pa_StartStream`s, started one right after the other - and using their separate "record" (capture) and "play" callbacks * By using a single `PaStream*`, which correspondingly has only one callback ("wire" callback), which handles memory copying in both playback and capture directions In Audacity, as far as I could see, there is only one PortAudio callback defined (audacity-1.3.13/src/AudioIO.cpp has audacityAudioCallback;), so Audacity basically has a single "wire" callback for full-duplex. Because of that, both Audacity and `patest_duplex_wire.c` (when using a single stream/"wire" callback), can enter this section of portaudio-v19/src/hostapi/alsa/pa_linux_alsa.c: if( !xrun ) { /* Get the number of available frames for the pcms that are marked ready. * @concern FullDuplex If only one direction is marked ready (from poll), the number of frames available for * the other direction is returned. Output is normally preferred over capture however, so capture frames may be * discarded to avoid overrun unless paNeverDropInput is specified. */ int captureReady = self->capture.pcm ? self->capture.ready : 0, playbackReady = self->playback.pcm ? self->playback.ready : 0; PA_ENSURE( PaAlsaStream_GetAvailableFrames( self, captureReady, playbackReady, framesAvail, &xrun ) ); if( self->capture.pcm && self->playback.pcm ) { if( !self->playback.ready && !self->neverDropInput ) { /* Drop input, a period's worth */ PA_MDEBUG(( "%s: full-duplex (not xrun): Drop input, a period's worth - fra:%lu \n", __FUNCTION__, *framesAvail )); //added assert( self->capture.ready ); PaAlsaStreamComponent_EndProcessing( &self->capture, PA_MIN( self->capture.framesPerBuffer, *framesAvail ), &xrun ); *framesAvail = 0; self->capture.ready = 0; } } else if( self->capture.pcm ) assert( self->capture.ready ); else assert( self->playback.ready ); } ... ... which is precisely the section that seems to be causing the full-duplex capture drops I experience. I think I tried `neverDropInput` with `patest_duplex_wire.c`, and it kept segfaulting - but in any case, I don't think Audacity (at least this version) has any UI to manipulate this parameter; so I'd rather code the ALSA driver properly, so PortAudio thinks it's getting a proper full-duplex stream from it. However, this is where I get stuck - because all I can see in the code snippet are boolean conditions. Thus I cannot see what the condition is to enter this segment - in terms of variables visible from the ALSA driver (like dpcm->pcm_buf_pos, or snd_pcm_capture_avail/_hw_avail(substream->runtime)). In other words, I'd like to know what sort of rule should the ALSA driver variables observe, so the above "drop input" section is never entered when using a single PortAudio stream/"wire" callback. This is the reason why I tried adding some extra debugging statements to PortAudio (see `audacity-portaudio.patch` in the online folder), to obtain logs through `ftrace` - in hope that I'd get accurate timestamps from both user- and kernel- space, against which variable values from logs could be plotted. In brief, some of the variables on the plots are: * frabCC/frabPC = framesAvail (Capture/Playback) in bytes from CallbackThreadFunc (pa_linux_alsa.c) * frabCW/frabPW = framesAvail (Capture/Playback) in bytes from PaAlsaStream_WaitForFrames (pa_linux_alsa.c) * frgbtc/frgbtp = framesGot (Capture/Playback) in bytes total (cumulative); CallbackThreadFunc (pa_linux_alsa.c) * pav/cav/phwav/chwav = snd_pcm_playback/capture_avail/_hw_avail(substream->runtime) in bytes (dummy-2.6.32-patest.c) * aptbC/aptbP/hptbC/hptbP = (Capture/Playback) substream->runtime->control->appl_ptr/hw_ptr in bytes (dummy-2.6.32-patest.c) [ When a single PortAudio "wire" callback is used, only frabCC, frabCW and frgbtc appear (there are no separate playback variants then) - however, the driver still has separate timer functions/tasklets for each direction (playback or capture). ] The original `dummy` driver has code for both Linux kernel system timers, and for high-resolution timers; the driver builds on my system automatically with hrtimers, which is what I'm interested in. Initially, I started by working with hrtimer functions set to a period of one jiffy: since HZ in my OS is defined as 250, one jiffy is 1/HZ = 1/250 = 4 ms - and then I calculated bytes per period as total bytes per second 44100*2*2 = 176400 divided by HZ, which gives 176400/250 = 705.6 ; and then I tried to increase dpcm->pcm_buf_pos with 705 each time the hrtimer tasklet was called (those captures have folder names ending with `_jif`). That results in a behavior like this: http://sdaaubckp.sourceforge.net/post/alsa-patest-duplex/captures_02_jif/tr… That is a capture with driver debug tracing (D), fixed bytes per period in driver (F), playback+record callbacks in `patest_duplex_wire.c` (pr), with request of 512 FRAMES_PER_BUFFER (512). What I find surprising here, is that driver's `chwav` (and `cav`) stay mostly constant, "resetting" themselves in just three "hits" of the timer/tasklet after 0.12 sec; while `pav` slowly raises (and `phwav` slowly falls) - until a point after 0.12 sec, where they "reset" themselves in just one "hit" of the timer function. Furthermore, `frabPC`, `frabCC` and `frabPW` also follow the `pav` line (indicating that some frames were left 'avail', after the requested 512 frames were 'got' in PA's `CallbackThreadFunc`). For a while I thought that this slow "raise" was the cause for the drop - but it isn't, as that particular capture doesn't display a drop (and it cannot either, because it doesn't use a single "wire" callback) Then, I thought that the reason for the `pav` rising slope could be, that I'm taking too much time processing in the driver callbacks; but that can't be it, because the capture above is obtained with the "snd-dummy" driver - which does pretty much nothing in its hrtimer/takslet function, but increasing the pcm_buf_pos counters (and memsetting a couple of bytes in the capture direction); I cannot really see that as a CPU hog?! Then I thought, maybe it's a rounding problem, since I should be increasing driver pointers by 705.6 bytes per timer tick, and I'm increasing for 705 bytes instead - but then, that should result with _less_ data available for playback; while `pav` rising implies that _more_ data than needed is delivered to the PortAudio callback. Then I did another test, trying to check the delta between the kernel timestamps for capture and playback driver tasklets separately; it turns out, even if the period is specified as 4000000e-9 nsecs (4 ms) - the deltas still gr avitate around 3.99x ms; I tried also calculating cumulative bytes per second (based on deltas and bytes per period) - and for different captures, they typically tended to stabilize to some +80 Bps to some +100 Bps above the required (176400 Bps). So, if the hrtimer indeed runs a bit faster, then indeed we may feed more data than needed from the driver to userspace (PA) - but then again, the slope of `pav` is at least 668 bytes for 12.6 ms, which is >> 80 Bps; so I'm still not sure where exactly does that slope come from. Then, I noticed that the original `dummy.c` driver doesn't increase its counters by a fixed amount of bytes - but instead, by what I'd call "adaptive" amount of bytes: delta to a base time is taken; and it can be used to calculate the expected (wrapped) buffer position depending on the requested rate (although `dummy.c` does this in frames, and does it in the `_pointer` callback). So I did the same in the hrtimer tasklet - and, this seemingly does very little in respect to the `pav` slope: http://sdaaubckp.sourceforge.net/post/alsa-patest-duplex/captures_02_jif/tr… ... which is still present, with nearly the same slope as before. Unfortunately, passing "adaptive" amount of bytes/frames around is not the solution to the drops either - because here is a capture of a "drop input" (`frabDI`), with single "wire" callback requesting 512 FRAMES_PER_BUFFER - happening at approx 60 ms, even before the first correction happens (after 0.12 sec): http://sdaaubckp.sourceforge.net/post/alsa-patest-duplex/captures_02_jif/tr… The only thing I can notice here, is that when the drop happens, `phwav` briefly "crosses" below the value of `pav` (which otherwise never happens; the same goes for cav/chwav) - but I'm not sure if this is the cause, or the effect, of the drop. Also, it can be noted that for a PA single "wire" callback, the driver's playback and capture hrtimer tasklets hit very close to each other, and the corresponding variables are also very close - at the above resolution, the trace points for both nearly overlap. Another thing I suspected was FRAMES_PER_BUFFER in the PortAudio program, so the test script switches the setting in `patest_duplex_wire.c` between 512 and 0 (which is `paFramesPerBufferUnspecified`). Note that when using 0 frames per buffer: http://sdaaubckp.sourceforge.net/post/alsa-patest-duplex/captures_02_jif/tr… ... and playback+record callbacks, the is no more long slope of `pav`/`phwav`, and it self-corrects more quickly; while `cav`/`chwav` stay nearly constant - however, also note the condition where `phwav` briefly "crosses" below the value of `pav`, appears here again (but no "drop input" is detected, because we're not using a single "wire" callback). However, not even FRAMES_PER_BUFFER=0 seems to help; as it doesn't prevent the "drop input" for a single "wire" callback, in the capture below: http://sdaaubckp.sourceforge.net/post/alsa-patest-duplex/captures_02_jif/tr… Since I was also suspecting the debug traces from the driver for having an influence on the drop, the debug traces are disabled for the driver (x) in that capture - and obviously, this is not the sole cause of the drop either. Note that the original `dummy.c` kernel module calculates the period in nanoseconds, so it matches the pcm period size; in that case, one does not have to calculate if the current buffer position went over a period size - but can, instead, issue `snd_pcm_period_elapsed` directly at each call of the hrtimer tasklet. In this case, say for a pcm_period_size: 512 bytes, we might get a hrtimer period of 2902495 ns = 2.9 ms. This is controlled by the USE_JIFFY_PERIOD variable in the `dummy-2.6.32-patest.c` driver code, though not controlled by the `run-alsa-pa-tests.sh` - thus it has to be enabled manually; captures which USE_JIFFY_PERIOD have `_jif` as extension to the folder name, those that match to period size have `_psz` as extension. Again, even this doesn't prevent occurrence of the full-duplex "drop input"s - in all, these of the provided captures in the .tar.gz file feature drops: captures_01_psz/trace_patest__07_DA_w_0_drop.csv captures_03_psz/trace_patest__16_DF_w_512_drop.csv captures_01_psz/trace_patest__15_DF_w_0_drop.csv captures_04_jif/trace_patest__03_xA_w_0_drop.csv captures_02_jif/trace_patest__03_xA_w_0_drop.csv captures_04_jif/trace_patest__07_DA_w_0_drop.csv captures_02_jif/trace_patest__07_DA_w_0_drop.csv captures_04_jif/trace_patest__11_xF_w_0_drop.csv captures_02_jif/trace_patest__08_DA_w_512_drop.csv captures_04_jif/trace_patest__15_DF_w_0_drop.csv captures_02_jif/trace_patest__11_xF_w_0_drop.csv captures_04_jif/trace_patest__16_DF_w_512_drop.csv captures_03_psz/trace_patest__07_DA_w_0_drop.csv As the filenames indicate: * Regardless of whether the driver tunes its timer period to a jiffy (_jif) or to the period size (_psz); * Regardless of whether I use trace debug statement in the driver (D), or not (x); * Regardless of whether the driver "returns" adaptive (A) or fixed (F) amount of bytes; * Regardless of whether we use paFramesPerBufferUnspecified=0 or 512 frames per buffer in PortAudio; ... as long as there is a single stream/"wire callback" used from PortAudio, a "drop input" is liable to happen when running `patest_duplex_wire.c` - and this, even with a virtual `dummy` driver, which has no communication with real hardware at all, and pretty much does nothing: its role of "reading"/"writing" or "returning" bytes is merely simulated by increasing the stream buffer position counters! The mind boggles - especially since, the way I see it, one should do nothing else but properly increase these buffer counters from the driver, in order to have PortAudio "believe" a "proper" full-duplex transfer is occurring?!... and yet, what this "proper" rule (of increasing driver buffer counters) should be, completely evades me. Here I'd also like to note a few other observations - first, note that when scaling the driver hrtimer period to the period size (_psz), the `pav`/`phwav` became nearly constant, in comparison to the slopes still present upon FRAMES_PER_BUFFER=0 (which confuses me, since both: 705 bytes @ 4ms; and 2.9 bytes @ 2.9ms; should both be nearly as close to a rate of 44100 frames = 176400 bytes per second): http://sdaaubckp.sourceforge.net/post/alsa-patest-duplex/captures_03_psz/tr… ... but then, as the filenames above indicate, drops happen even then - although somewhat less often, and only when debug tracing in the driver is enabled. Could it be, that debug tracing directly from the driver can have such an effect on performance, so as to influence appearance of full-duplex "drop inputs" - even if precautions were taken, such as using `ftrace`s `trace_printk` (instead of the usual syslog `printk`), and piping the debug output directly to RAM (by using `/dev/shm`)? On a scale of a complete capture, I'd usually expect all cumulative pointers to essentially follow a single line; and usually when a capture goes well, that is how it appears - like on the image below: http://sdaaubckp.sourceforge.net/post/alsa-patest-duplex/captures_04_jif/tr… While it may be a bit difficult to follow all variables (recreate the plot in the interactive `wxt` terminal in `gnuplot`, to be able to turn off individual function plots), they all generally follow each other in the same general slope; also note that the capture ends at about 2 seconds (as programmed in `patest_duplex_wire.c`) - but playback lingers on for half a second more. However, a full-duplex drop can seemingly happen even on a line that otherwise appears straight - like on the plot below (although the reason for that could be that the drop happens early in that capture): http://sdaaubckp.sourceforge.net/post/alsa-patest-duplex/captures_02_jif/tr… ... but usually, a "drop input" resets (at least) the driver's playback `hw_ptr` (and others), like on the capture below: http://sdaaubckp.sourceforge.net/post/alsa-patest-duplex/captures_04_jif/tr… Note that when using playback/record PA callbacks (which cannot detect a "drop input"), may have similar resets of playback `hw_ptr`: http://sdaaubckp.sourceforge.net/post/alsa-patest-duplex/captures_03_psz/tr… ... but also the capture variables may reset: http://sdaaubckp.sourceforge.net/post/alsa-patest-duplex/captures_03_psz/tr… The above capture also shows `frgbtc` starting to deviate from `frgbtp`, when these "resets" occur - but piecewise, `frgbtc` still seems to keep slope parallel to `frgbtp` (and the rest of the cumulative position variables). However, this seems to be a case of proper XRUN, as the respective log for that capture includes "PaAlsaStream_HandleXrun: restarting Alsa to recover from XRUN" (while the full-duplex "drop input" is specifically _not_ an xrun). Note also, that sometimes I get some variables to be completely non-linear: http://sdaaubckp.sourceforge.net/post/alsa-patest-duplex/captures_01_psz/tr… ... however, note also that `captures_01_psz` was taken with an older version of the scripts, where I may have possibly failed to increase `ftrace` buffering - so I think those interruptions in the capture data are actually an artifact of a tracing problem. Otherwise, is it possible that ALSA could "pause" the playback/capture hrtimer tasklets for a while? Interestingly, when I tried using `patest_duplex_wire.c` with my onboard HDA Intel soundcard (naturally, without any kernel driver variable tracing, only the PA part) - a lot of the times it ended up producing similar non-linear (and diverging) cumulative variable traces - however, it never triggered a full-duplex "drop input". Finally, I suspect that these settings in the `dummy-2.6.32-patest.c` module, may also play a role in the behavior that results with full-duplex drops (they are otherwise kept the same as in the original `dummy` module): static struct snd_pcm_hardware dummy_pcm_hardware = { .info = (SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_RESUME | SNDRV_PCM_INFO_MMAP_VALID), ... .buffer_bytes_max = MAX_BUFFER_SIZE, .period_bytes_min = 64, .period_bytes_max = MAX_PERIOD_SIZE, //(64*1024) .periods_min = USE_PERIODS_MIN, //1 .periods_max = USE_PERIODS_MAX, //1024 .fifo_size = 0, ... ... and my questions in respect to them, would be this (considering the capture data should be available through address substream->runtime->dma_area in the driver): * Given that this is a virtual driver, there is no hardware with buffers whose status (how filled they are) could generate (hardware) interrupts; instead we "raise" hrtimer functions (softirq priority) directly from the kernel module - which further schedule a tasklet (with even lower priority), and where we have the opportunity to control the repetition period of the timer functions (and thus the expected transferred bytes per period, for a given audio rate). In this context, what is the meaning of `period_bytes_min` and `periods_min`? Can they be arbitrarily set - or should one set them in relation to the expected bytes per period achieved through the timer functions? * Given that `dummy` is a virtual driver, and doesn't communicate with hardware - there is no actual DMA operation performed through it, right? * If there is no actual DMA - is there actual MMAP? In other words, does the MMAP in SNDRV_PCM_INFO_MMAP refer to: memory mapping of a hardware card DMA bus address, to substream->runtime->dma_area; or to: memory mapping of kernel-space substream->runtime->dma_area, to whatever address user-space (e.g. snd_pcm_read()) uses to access it? * If there is no actual DMA - should SNDRV_PCM_INFO_MMAP_VALID be then kept? (original `dummy` driver keeps it) What would be the meaning of SNDRV_PCM_INFO_MMAP_VALID in this context (of a virtual driver with hrtimer functions/tasklets?) * What would be the meaning of SNDRV_PCM_INFO_JOINT_DUPLEX in this context? (I've seen [http://mailman.alsa-project.org/pipermail/alsa-devel/2007-December/004801.h… "[alsa-devel] How do I use SNDRV_PCM_INFO_JOINT_DUPLEX?"], but I can't really relate it to this context) Could usage of SNDRV_PCM_INFO_JOINT_DUPLEX help avoid the PortAudio full-duplex drops? And to summarize my general questions: * Given the 'telecom' definition of full-duplex as "a point-to-point system composed of two connected parties or devices that can communicate with one another in both directions, simultaneously" (wiki), is there a stricter/more specific definition of "full-duplex": ** in terms of digital audio generally? ** specifically in PortAudio (I guess yes: "when a single callback is used for both playback and capture", but there's probably more in terms of buffer positions), and in ALSA (I guess no)? * Given that none of the approaches used in the test (debug driver traces on vs. off; driver returning fixed vs. adaptive number of frames/bytes per period; driver tuning the period to pcm_period_size vs. to a jiffy; PA using fixed vs. using unspecified amount of frames per period) have explicitly prevented the appearance of single "wire" callback (full-duplex) drops; and given that the driver is a virtual one (merely updating buffer positions, which shouldn't be a CPU hog) - what could possibly be the reason for the full-duplex drops? * Is it possible at all, to use the architecture of the `dummy` driver (hrtimer + tasklet just updating buffer positions) to code an ALSA driver, that will not generate full-duplex drops when used from PortAudio with single "wire" callback? ** If so, is there a metric/conditions in terms of ALSA driver variables, that should be followed to ensure proper full-duplex operation (under PortAudio with single callback)? * Is it possible that the driver is OK - and instead I have a problem with coding of the single "wire" callback in PortAudio? (even though most of it is copied from examples) Well, that was certainly a mouthful - but I hope at least I managed to provide a reproducible example, if not a coherent explanation of the problem... Thanks in advance for any answers/pointers, Cheers!

6 15

[alsa-devel] [PING!] Re: HDMI audio is not working on my new desktop
by Alexander E. Patrakov 05 Oct '13

05 Oct '13

2013/8/14 Alexander E. Patrakov <patrakov(a)gmail.com>: > Hello. > > I built a new desktop PC based on the Gigabyte H87N-WIFI motherboard. > It has one DVI and two HDMI outputs. However, I cannot get any sound > over HDMI. The same OS image works perfectly on my laptop that also > has an HDMI output. > > This is not a pulseaudio problem, as I don't get any sound even if I > test with this command: > > pasuspender -- speaker-test -c2 -D hdmi:0,2 # or, for that matter, 0,0 or 0,1 > > Alsa-info.sh has uploaded its output to > http://www.alsa-project.org/db/?f=1ad7192a15ff4a70b5ddb2579476dbb98adbd929 > > Please note this error in dmesg, it may be relevant: > > [ 1.803595] hda_codec: invalid CONNECT_LIST verb 5[1]:0 > [ 1.803719] hda_codec: invalid CONNECT_LIST verb 7[1]:0 As nobody replied, I have converted this into a formal bug report: https://bugzilla.kernel.org/show_bug.cgi?id=60769 Haswell people, _please_ comment on the bug. -- Alexander E. Patrakov

3 9

[alsa-devel] snd_device_name_hint segfaults
by Forest Bond 03 Oct '13

03 Oct '13

Hi, I'm seeing segfaults with VLC similar to those reported here: http://mailman.alsa-project.org/pipermail/alsa-devel/2013-January/059168.ht… This is on Ubuntu 12.04 with the latest alsa-lib package (1.0.25-1ubuntu10.2) and the following patches also applied: * 2cfc8b9b44a8e493c41b3d63d5a00b306a18a5ed snd_pcm_direct_parse_open_conf(): use thread-safe getgrnam_r() * 44c1a623dd1fc9e831616b663bebc54ca98df994 Add snd_lib_error_set_local() to install a thread-local error handler. * 25dbb102810b31c02358904d70d53c960fb0a10e snd_device_name_hint(): do not change the global error handler. * f49b2dc522a2564315c76d075203b15a39941e8a snd_device_name_hint(): do not use global snd_config. * 7f2b2c8c1650a1883b48abfcdb455138943854f9 conf: Fix a memory access violation resulting from improper error propogation So I think there are still issues when calling snd_device_name_hint(-1, ...). Here is the backtrace: #0 0x003f0e78 in __strcpy_chk () from /lib/i386-linux-gnu/libc.so.6 #1 0x0625084b in strcpy (__src=0x0, __dest=0xb6025e80 "pcm.(null)") at /usr/include/i386-li nux-gnu/bits/string3.h:105 #2 try_config (config=0xaf1c4df0, list=0xb52fe804, base=0x323e962 "pcm", name=0x0) at nameh int.c:243 #3 0x06251bc5 in add_software_devices (list=0xb52fe804, config=0xaf1c4df0) at namehint.c:51 2 #4 snd_device_name_hint (card=-1, iface=<optimized out>, hints=0xb52fe90c) at namehint.c:59 1 #5 0x0323c9bb in GetDevices (obj=0xb6271700, item=0x0, prefs_dev=<optimized out>) at alsa.c :721 #6 0x0323d4c0 in Probe (dev=0xb6011df8 "default", obj=0xb6271700) at alsa.c:161 #7 Open (obj=0xb6271700) at alsa.c:539 #8 0x0a6c73d0 in generic_start (func=0x323cd10, ap=0xb52fed98 "\273") at modules/modules.c:422 #9 0x0a6c7a3a in vlc_module_load (p_this=0xb6271700, psz_capability=0xa70b959 "audio output", psz_name=<optimized out>, b_strict=false, probe=0xa6c73c0 <generic_start>) at modules/modules.c:347 #10 0x0a6c8002 in module_need (obj=0xb6271700, cap=0xa70b959 "audio output", name=0xa70d2bd "$aout", strict=false) at modules/modules.c:437 #11 0x0a6b1242 in aout_OutputNew (p_aout=0xb6271700, p_format=0xb52feeac) at audio_output/output.c:59 #12 0x0a6ad77f in aout_DecNew (p_aout=0xb6271700, p_format=0xb52feeac, p_replay_gain=0xaef02a14, p_request_vout=0xb52feed0) at audio_output/dec.c:112 #13 0x0a67066e in aout_new_buffer (p_dec=0xaef02870, i_samples=1024) at input/decoder.c:2286 #14 0x0a672690 in decoder_NewAudioBuffer (p_decoder=0xaef02870, i_size=1024) at input/decoder.c:213 #15 0x04032f8c in DecodeBlock (p_dec=0xaef02870, pp_block=0xb52ff05c) at faad.c:464 #16 0x0a670891 in DecoderDecodeAudio (p_dec=0xaef02870, p_block=0xaef03000) at input/decoder.c:1291 #17 0x0a6716f5 in DecoderProcessAudio (b_flush=false, p_block=0xaef03000, p_dec=0xaef02870) at input/decoder.c:1936 #18 DecoderProcess (p_dec=0xaef02870, p_block=<optimized out>) at input/decoder.c:2059 #19 0x0a671959 in DecoderThread (p_data=0xaef02870) at input/decoder.c:938 #20 0x001fbd4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 #21 0x003ddace in clone () from /lib/i386-linux-gnu/libc.so.6 As a work around I will probably patch VLC to not call snd_device_name_hint this way. I see this has been done for other applications: http://code.google.com/p/chromium/issues/detail?id=95797 http://code.mythtv.org/trac/ticket/10809 But I wanted to try diagnosing the issue first. Thoughts? Thanks, Forest -- Forest Bond http://www.alittletooquiet.net http://www.rapidrollout.com

4 6

[alsa-devel] [TINYCOMPRESS][PATCH 1/1] compress: Must check for POLLERR before POLLOUT/POLLIN
by Richard Fitzgerald 25 Sep '13

25 Sep '13

In the case of error the ALSA compressed driver sets revents as (POLLOUT | POLLWRNORM | POLLERR) or (POLLIN | POLLWRNORM | POLLERR). So we can't assume that POLLOUT or POLLIN indicate success, we must check for POLLERR first. Signed-off-by: Richard Fitzgerald <rf(a)opensource.wolfsonmicro.com> --- compress.c | 18 +++++++++--------- 1 files changed, 9 insertions(+), 9 deletions(-) diff --git a/compress.c b/compress.c index 0e71c28..5cd0966 100644 --- a/compress.c +++ b/compress.c @@ -378,6 +378,9 @@ int compress_write(struct compress *compress, const void *buf, unsigned int size return total; ret = poll(&fds, 1, compress->max_poll_wait_ms); + if (fds.revents & POLLERR) { + return oops(compress, EIO, "poll returned error!"); + } /* A pause will cause -EBADFD or zero. * This is not an error, just stop writing */ if ((ret == 0) || (ret == -EBADFD)) @@ -387,9 +390,6 @@ int compress_write(struct compress *compress, const void *buf, unsigned int size if (fds.revents & POLLOUT) { continue; } - if (fds.revents & POLLERR) { - return oops(compress, EIO, "poll returned error!"); - } } /* write avail bytes */ if (size > avail.avail) @@ -438,6 +438,9 @@ int compress_read(struct compress *compress, void *buf, unsigned int size) return total; ret = poll(&fds, 1, compress->max_poll_wait_ms); + if (fds.revents & POLLERR) { + return oops(compress, EIO, "poll returned error!"); + } /* A pause will cause -EBADFD or zero. * This is not an error, just stop reading */ if ((ret == 0) || (ret == -EBADFD)) @@ -447,9 +450,6 @@ int compress_read(struct compress *compress, void *buf, unsigned int size) if (fds.revents & POLLIN) { continue; } - if (fds.revents & POLLERR) { - return oops(compress, EIO, "poll returned error!"); - } } /* read avail bytes */ if (size > avail.avail) @@ -616,15 +616,15 @@ int compress_wait(struct compress *compress, int timeout_ms) fds.events = POLLOUT | POLLIN; ret = poll(&fds, 1, timeout_ms); + if (fds.revents & POLLERR) { + return oops(compress, EIO, "poll returned error!"); + } /* A pause will cause -EBADFD or zero. */ if ((ret < 0) && (ret != -EBADFD)) return oops(compress, errno, "poll error"); if (fds.revents & (POLLOUT | POLLIN)) { return 0; } - if (fds.revents & POLLERR) { - return oops(compress, EIO, "poll returned error!"); - } return ret; } -- 1.7.2.5

2 1

[alsa-devel] Audio Miniconference 2013 - Edinburgh 21st October
by Mark Brown 24 Sep '13

24 Sep '13

As in previous years we're planning to have an audio mini-summit to bring everyone together to discuss the current state of audio in Linux, try to resolve outstanding design issues and do some hacking. This year we will be meeting in Edinburgh on 21st October as part of the Linux Foundation conferences being held that week. What topics would people like to discuss? There are a number of ongoing issues like DSP integration and related topics such as compressed audio and I know that there are some issues which have come up while people have been working on deploying UCM especially with PulseAudio integration. What other areas are of interest to people? To help with planning could you please fill out the form at: https://docs.google.com/forms/d/105uav9tkwwkDU4P1T3IOWjfsa3kgtDbFAJOlHgBQR5… if you're planning to attend, ideally by 21st September. Since the facilities are being provided by the Linux Foundation attendees will need to be registered for at least one of the other conferences that week, if that's an issue please let us know. There's a space for topics of interest on the form but please also bring things up on the list so other people can get a feel for what's going on and ideally so we can resolve them all via e-mail!

2 2

[alsa-devel] Buffer size for ALSA USB PCM audio
by Alan Stern 22 Sep '13

22 Sep '13

I have been studying the data_ep_set_params() function in sound/usb/endpoint.c. This is the routine that calculates the number of samples and I/O requests to keep on the USB hardware queue for PCM audio, based on the ALSA parameters. It uses the PERIOD_BYTES parameter but not BUFFER_BYTES. In simplified terms (ignoring rounding, boundary cases, and other things), the number of periods per buffer is fixed at 24 for recording and 1 for playback, completely ignoring the user's setting. If you look at the parameters copied in snd_usb_hw_params() in sound/usb/pcm.c, you'll see what I mean. Is this really the intended behavior? It doesn't seem right at all. Alan Stern

7 44