July 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] 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] 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

[alsa-devel] No sound with Sony VAIO VPCZ1 (ALC889)
by Tormen 20 Sep '13

20 Sep '13

Hi, alsa-driver: 1.0.25.3453.g60df0 (the latest I guess -- I used alsa-compile.sh) Kernel: 3.9.6-1~bpo70+1 (debian 7.1 backport) Problem: Sound works fine, except that no speaker gets detected. The internal speakers in my Sony VAIO VPCZ1 notebook did get detected in the past though. If I am not mistaken, this is the problem: [ 5.864681] ALSA hda_auto_parser.c:397 speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) alsa-info.sh: !!################################ !!ALSA Information Script v 0.4.62 !!################################ !!Script ran on: Wed Jul 3 17:38:37 UTC 2013 !!Linux Distribution !!------------------ Debian GNU/Linux 7 \n \l PRETTY_NAME="Debian GNU/Linux 7 (wheezy)" NAME="Debian GNU/Linux" ID=debian HOME_URL="http://www.debian.org/" SUPPORT_URL="http://www.debian.org/support/" BUG_REPORT_URL="http://bugs.debian.org/" !!DMI Information !!--------------- Manufacturer: Sony Corporation Product Name: VPCZ1290S Product Version: J0049ZZ5 Firmware Version: R3030C3 !!Kernel Information !!------------------ Kernel release: 3.9-0.bpo.1-amd64 Operating System: GNU/Linux Architecture: x86_64 Processor: unknown SMP Enabled: Yes !!ALSA Version !!------------ Driver version: 1.0.25.3453.g60df0 Library version: 1.0.25 Utilities version: 1.0.25 !!Loaded ALSA modules !!------------------- snd_hda_intel !!Sound Servers on this system !!---------------------------- Pulseaudio: Installed - Yes (/usr/bin/pulseaudio) Running - Yes !!Soundcards recognised by ALSA !!----------------------------- 0 [MID ]: HDA-Intel - HDA Intel MID HDA Intel MID at 0xb6420000 irq 45 !!PCI Soundcards installed in the system !!-------------------------------------- 00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset High Definition Audio (rev 05) !!Advanced information - PCI Vendor/Device/Subsystem ID's !!------------------------------------------------------- 00:1b.0 0403: 8086:3b56 (rev 05) Subsystem: 104d:905a !!Modprobe options (Sound related) !!-------------------------------- snd_pcsp: index=-2 snd_usb_audio: index=-2 snd_atiixp_modem: index=-2 snd_intel8x0m: index=-2 snd_via82xx_modem: index=-2 snd_hda_intel: model=no-primary-hp !!Loaded sound module options !!--------------------------- !!Module: snd_hda_intel align_buffer_size : -1 bdl_pos_adj : 32,-1,-1,-1,-1,-1,-1,-1 beep_mode : Y,Y,Y,Y,Y,Y,Y,Y enable : Y,Y,Y,Y,Y,Y,Y,Y enable_msi : -1 id : (null),(null),(null),(null),(null),(null),(null),(null) index : -1,-1,-1,-1,-1,-1,-1,-1 jackpoll_ms : 0,0,0,0,0,0,0,0 model : no-primary-hp,(null),(null),(null),(null),(null),(null),(null) patch : (null),(null),(null),(null),(null),(null),(null),(null) position_fix : -1,-1,-1,-1,-1,-1,-1,-1 power_save : 0 power_save_controller : Y probe_mask : -1,-1,-1,-1,-1,-1,-1,-1 probe_only : 0,0,0,0,0,0,0,0 single_cmd : N snoop : Y !!HDA-Intel Codec information !!--------------------------- --startcollapse-- Codec: Realtek ALC889 Address: 0 AFG Function Id: 0x1 (unsol 1) Vendor Id: 0x10ec0889 Subsystem Id: 0x104d4400 Revision Id: 0x100005 No Modem Function Group found Default PCM: rates [0x5f0]: 32000 44100 48000 88200 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Default Amp-In caps: N/A Default Amp-Out caps: N/A State of AFG node 0x01: Power states: D0 D1 D2 D3 CLKSTOP EPSS Power: setting=D0, actual=D0 GPIO: io=2, o=0, i=0, unsolicited=1, wake=1 IO[0]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[1]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 Node 0x02 [Audio Output] wcaps 0x11: Stereo Device: name="ALC889 Analog", type="Audio", device=0 Converter: stream=8, channel=0 PCM: rates [0x5e0]: 44100 48000 88200 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Node 0x03 [Audio Output] wcaps 0x11: Stereo Converter: stream=8, channel=0 PCM: rates [0x5e0]: 44100 48000 88200 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Node 0x04 [Audio Output] wcaps 0x11: Stereo Converter: stream=8, channel=0 PCM: rates [0x5e0]: 44100 48000 88200 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Node 0x05 [Audio Output] wcaps 0x11: Stereo Converter: stream=8, channel=0 PCM: rates [0x5e0]: 44100 48000 88200 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Node 0x06 [Audio Output] wcaps 0x211: Stereo Digital Converter: stream=0, channel=0 Digital: Digital category: 0x0 IEC Coding Type: 0x0 PCM: rates [0x5f0]: 32000 44100 48000 88200 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Node 0x07 [Audio Input] wcaps 0x10011b: Stereo Amp-In Control: name="Capture Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Capture Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Device: name="ALC889 Analog", type="Audio", device=0 Amp-In caps: ofs=0x10, nsteps=0x2e, stepsize=0x03, mute=1 Amp-In vals: [0x28 0x28] Converter: stream=4, channel=0 SDI-Select: 0 PCM: rates [0x5e0]: 44100 48000 88200 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Connection: 1 0x24 Node 0x08 [Audio Input] wcaps 0x10011b: Stereo Amp-In Amp-In caps: ofs=0x10, nsteps=0x2e, stepsize=0x03, mute=1 Amp-In vals: [0x90 0x90] Converter: stream=0, channel=0 SDI-Select: 0 PCM: rates [0x5e0]: 44100 48000 88200 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Connection: 1 0x23 Node 0x09 [Audio Input] wcaps 0x10011b: Stereo Amp-In Amp-In caps: ofs=0x10, nsteps=0x2e, stepsize=0x03, mute=1 Amp-In vals: [0x90 0x90] Converter: stream=0, channel=0 SDI-Select: 0 PCM: rates [0x5e0]: 44100 48000 88200 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Connection: 1 0x22 Node 0x0a [Audio Input] wcaps 0x100391: Stereo Digital Converter: stream=0, channel=0 SDI-Select: 0 Digital: Digital category: 0x0 IEC Coding Type: 0x0 PCM: rates [0x570]: 32000 44100 48000 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Unsolicited: tag=00, enabled=0 Connection: 1 0x1f Node 0x0b [Audio Mixer] wcaps 0x20010b: Stereo Amp-In Control: name="Mic Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Mic Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Mic Playback Volume", index=1, device=0 ControlAmp: chs=3, dir=In, idx=1, ofs=0 Control: name="Mic Playback Switch", index=1, device=0 ControlAmp: chs=3, dir=In, idx=1, ofs=0 Control: name="Beep Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=5, ofs=0 Control: name="Beep Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=5, ofs=0 Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1 Amp-In vals: [0x8f 0x8f] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] Connection: 10 0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x14 0x15 0x16 0x17 Node 0x0c [Audio Mixer] wcaps 0x20010f: Stereo Amp-In Amp-Out Control: name="Headphone Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x00 0x00] [0x00 0x00] Amp-Out caps: ofs=0x3e, nsteps=0x40, stepsize=0x03, mute=0 Amp-Out vals: [0x3e 0x3e] Connection: 2 0x02 0x0b Node 0x0d [Audio Mixer] wcaps 0x20010f: Stereo Amp-In Amp-Out Control: name="Surround Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x80 0x80] [0x80 0x80] Amp-Out caps: ofs=0x3e, nsteps=0x40, stepsize=0x03, mute=0 Amp-Out vals: [0x3e 0x3e] Connection: 2 0x03 0x0b Node 0x0e [Audio Mixer] wcaps 0x20010f: Stereo Amp-In Amp-Out Control: name="Center Playback Volume", index=0, device=0 ControlAmp: chs=1, dir=Out, idx=0, ofs=0 Control: name="LFE Playback Volume", index=0, device=0 ControlAmp: chs=2, dir=Out, idx=0, ofs=0 Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x80 0x80] [0x80 0x80] Amp-Out caps: ofs=0x3e, nsteps=0x40, stepsize=0x03, mute=0 Amp-Out vals: [0x3e 0x3e] Connection: 2 0x04 0x0b Node 0x0f [Audio Mixer] wcaps 0x20010f: Stereo Amp-In Amp-Out Control: name="Speaker Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x00 0x00] [0x00 0x00] Amp-Out caps: ofs=0x3e, nsteps=0x40, stepsize=0x03, mute=0 Amp-Out vals: [0x40 0x40] Connection: 2 0x05 0x0b Node 0x10 [Audio Output] wcaps 0x211: Stereo Digital Converter: stream=0, channel=0 Digital: Digital category: 0x0 IEC Coding Type: 0x0 PCM: rates [0x5f0]: 32000 44100 48000 88200 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Node 0x11 [Pin Complex] wcaps 0x400300: Mono Digital Pincap 0x00000010: OUT Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x40: OUT Connection: 1 0x10 Node 0x12 [Pin Complex] wcaps 0x400001: Stereo Control: name="Internal Mic Phantom Jack", index=0, device=0 Pincap 0x00000020: IN Pin Default 0x90a60120: [Fixed] Mic at Int N/A Conn = Digital, Color = Unknown DefAssociation = 0x2, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x20: IN Node 0x13 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x14 [Pin Complex] wcaps 0x40018d: Stereo Amp-Out Control: name="Speaker Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Control: name="Speaker Phantom Jack", index=0, device=0 Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x0001003c: IN OUT HP EAPD Detect EAPD 0x2: EAPD Pin Default 0x90170110: [Fixed] Speaker at Int N/A Conn = Analog, Color = Unknown DefAssociation = 0x1, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x40: OUT Unsolicited: tag=00, enabled=0 Connection: 5 0x0c 0x0d 0x0e 0x0f* 0x26 Node 0x15 [Pin Complex] wcaps 0x40018d: Stereo Amp-Out Control: name="Headphone Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Control: name="Headphone Jack", index=0, device=0 Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x0001003c: IN OUT HP EAPD Detect EAPD 0x2: EAPD Pin Default 0x0421101f: [Jack] HP Out at Ext Right Conn = 1/8, Color = Black DefAssociation = 0x1, Sequence = 0xf Pin-ctls: 0xc0: OUT HP Unsolicited: tag=01, enabled=1 Connection: 5 0x0c* 0x0d 0x0e 0x0f 0x26 Node 0x16 [Pin Complex] wcaps 0x40018d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Pincap 0x00000034: IN OUT Detect Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x00: Unsolicited: tag=00, enabled=0 Connection: 5 0x0c 0x0d 0x0e* 0x0f 0x26 Node 0x17 [Pin Complex] wcaps 0x40018d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Pincap 0x00000034: IN OUT Detect Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x00: Unsolicited: tag=00, enabled=0 Connection: 5 0x0c 0x0d 0x0e 0x0f* 0x26 Node 0x18 [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out Control: name="Surround Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Control: name="Mic Boost Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Mic Jack", index=0, device=0 Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Amp-In vals: [0x00 0x00] Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x0000373c: IN OUT HP Detect Vref caps: HIZ 50 GRD 80 100 Pin Default 0x04a1102e: [Jack] Mic at Ext Right Conn = 1/8, Color = Black DefAssociation = 0x2, Sequence = 0xe Pin-ctls: 0x24: IN VREF_80 Unsolicited: tag=02, enabled=1 Connection: 5 0x0c 0x0d 0x0e 0x0f 0x26* Node 0x19 [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out Control: name="Center Playback Switch", index=0, device=0 ControlAmp: chs=1, dir=Out, idx=0, ofs=0 Control: name="LFE Playback Switch", index=0, device=0 ControlAmp: chs=2, dir=Out, idx=0, ofs=0 Control: name="Mic Boost Volume", index=1, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Mic Jack", index=1, device=0 Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Amp-In vals: [0x00 0x00] Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x0000373c: IN OUT HP Detect Vref caps: HIZ 50 GRD 80 100 Pin Default 0x04a11030: [Jack] Mic at Ext Right Conn = 1/8, Color = Black DefAssociation = 0x3, Sequence = 0x0 Pin-ctls: 0x24: IN VREF_80 Unsolicited: tag=03, enabled=1 Connection: 5 0x0c 0x0d 0x0e 0x0f 0x26* Node 0x1a [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Amp-In vals: [0x00 0x00] Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Pincap 0x0000373c: IN OUT HP Detect Vref caps: HIZ 50 GRD 80 100 Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x20: IN VREF_HIZ Unsolicited: tag=00, enabled=0 Connection: 5 0x0c 0x0d 0x0e 0x0f 0x26* Node 0x1b [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Amp-In vals: [0x00 0x00] Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Pincap 0x0000373c: IN OUT HP Detect Vref caps: HIZ 50 GRD 80 100 Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x20: IN VREF_HIZ Unsolicited: tag=00, enabled=0 Connection: 5 0x0c 0x0d 0x0e 0x0f 0x26* Node 0x1c [Pin Complex] wcaps 0x400081: Stereo Pincap 0x00000024: IN Detect Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x20: IN Unsolicited: tag=00, enabled=0 Node 0x1d [Pin Complex] wcaps 0x400000: Mono Pincap 0x00000020: IN Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x20: IN Node 0x1e [Pin Complex] wcaps 0x400300: Mono Digital Pincap 0x00000010: OUT Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x40: OUT Connection: 1 0x06 Node 0x1f [Pin Complex] wcaps 0x400280: Mono Digital Pincap 0x00000020: IN Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x20: IN Unsolicited: tag=00, enabled=0 Node 0x20 [Vendor Defined Widget] wcaps 0xf00040: Mono Processing caps: benign=0, ncoeff=28 Node 0x21 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x22 [Audio Mixer] wcaps 0x20010b: Stereo Amp-In Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] Connection: 11 0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x14 0x15 0x16 0x17 0x0b Node 0x23 [Audio Mixer] wcaps 0x20010b: Stereo Amp-In Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] Connection: 11 0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x14 0x15 0x16 0x17 0x0b Node 0x24 [Audio Selector] wcaps 0x300101: Stereo Connection: 12 0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x14 0x15 0x16 0x17 0x0b 0x12* Node 0x25 [Audio Output] wcaps 0x11: Stereo Converter: stream=0, channel=0 PCM: rates [0x5e0]: 44100 48000 88200 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Node 0x26 [Audio Mixer] wcaps 0x20010f: Stereo Amp-In Amp-Out Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x00 0x00] [0x80 0x80] Amp-Out caps: ofs=0x3e, nsteps=0x40, stepsize=0x03, mute=0 Amp-Out vals: [0x3e 0x3e] Connection: 2 0x25 0x0b --endcollapse-- !!ALSA Device nodes !!----------------- crw-rw---T+ 1 root audio 116, 0 Jul 3 19:35 /dev/snd/controlC0 crw-rw---T+ 1 root audio 116, 4 Jul 3 19:35 /dev/snd/hwC0D0 crw-rw---T+ 1 root audio 116, 24 Jul 3 19:36 /dev/snd/pcmC0D0c crw-rw---T+ 1 root audio 116, 16 Jul 3 19:36 /dev/snd/pcmC0D0p crw-rw---T+ 1 root audio 116, 1 Jul 3 19:35 /dev/snd/seq crw-rw---T+ 1 root audio 116, 33 Jul 3 19:35 /dev/snd/timer /dev/snd/by-path: total 0 drwxr-xr-x 2 root root 60 Jul 3 19:35 . drwxr-xr-x 3 root root 180 Jul 3 19:35 .. lrwxrwxrwx 1 root root 12 Jul 3 19:35 pci-0000:00:1b.0 -> ../controlC0 !!ALSA configuration files !!------------------------ !!System wide config file (/etc/asound.conf) pcm.pulse { type pulse } ctl.pulse { type pulse } pcm.!default { type pulse } ctl.!default { type pulse } !!Aplay/Arecord output !!-------------------- APLAY **** List of PLAYBACK Hardware Devices **** card 0: MID [HDA Intel MID], device 0: ALC889 Analog [ALC889 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 ARECORD **** List of CAPTURE Hardware Devices **** card 0: MID [HDA Intel MID], device 0: ALC889 Analog [ALC889 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 !!Amixer output !!------------- !!-------Mixer controls for card 0 [MID] Card hw:0 'MID'/'HDA Intel MID at 0xb6420000 irq 45' Mixer name : 'Realtek ALC889' Components : 'HDA:10ec0889,104d4400,00100005' Controls : 34 Simple ctrls : 18 Simple mixer control 'Master',0 Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum Playback channels: Mono Limits: Playback 0 - 64 Mono: Playback 64 [100%] [0.00dB] [on] Simple mixer control 'Headphone',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 64 Mono: Front Left: Playback 62 [97%] [0.00dB] [on] Front Right: Playback 62 [97%] [0.00dB] [on] Simple mixer control 'Speaker',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 64 Mono: Front Left: Playback 64 [100%] [2.00dB] [on] Front Right: Playback 64 [100%] [2.00dB] [on] Simple mixer control 'PCM',0 Capabilities: pvolume penum Playback channels: Front Left - Front Right Limits: Playback 0 - 255 Mono: Front Left: Playback 255 [100%] [0.00dB] Front Right: Playback 255 [100%] [0.00dB] Simple mixer control 'Surround',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 64 Mono: Front Left: Playback 62 [97%] [0.00dB] [on] Front Right: Playback 62 [97%] [0.00dB] [on] Simple mixer control 'Center',0 Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum Playback channels: Mono Limits: Playback 0 - 64 Mono: Playback 62 [97%] [0.00dB] [on] Simple mixer control 'LFE',0 Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum Playback channels: Mono Limits: Playback 0 - 64 Mono: Playback 62 [97%] [0.00dB] [on] Simple mixer control 'Mic',0 Capabilities: pvolume pswitch cswitch cswitch-joined cswitch-exclusive penum Capture exclusive group: 0 Playback channels: Front Left - Front Right Capture channels: Mono Limits: Playback 0 - 31 Mono: Capture [off] Front Left: Playback 15 [48%] [-12.00dB] [off] Front Right: Playback 15 [48%] [-12.00dB] [off] Simple mixer control 'Mic 1',0 Capabilities: cswitch cswitch-joined cswitch-exclusive penum Capture exclusive group: 0 Capture channels: Mono Mono: Capture [off] Simple mixer control 'Mic Boost',0 Capabilities: volume penum Playback channels: Front Left - Front Right Capture channels: Front Left - Front Right Limits: 0 - 3 Front Left: 0 [0%] [0.00dB] Front Right: 0 [0%] [0.00dB] Simple mixer control 'Mic',1 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 31 Mono: Front Left: Playback 0 [0%] [-34.50dB] [off] Front Right: Playback 0 [0%] [-34.50dB] [off] Simple mixer control 'Mic Boost',1 Capabilities: volume penum Playback channels: Front Left - Front Right Capture channels: Front Left - Front Right Limits: 0 - 3 Front Left: 0 [0%] [0.00dB] Front Right: 0 [0%] [0.00dB] Simple mixer control 'Beep',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 31 Mono: Front Left: Playback 0 [0%] [-34.50dB] [off] Front Right: Playback 0 [0%] [-34.50dB] [off] Simple mixer control 'Capture',0 Capabilities: cvolume cswitch penum Capture channels: Front Left - Front Right Limits: Capture 0 - 46 Front Left: Capture 40 [87%] [24.00dB] [on] Front Right: Capture 40 [87%] [24.00dB] [on] Simple mixer control 'Auto-Mute Mode',0 Capabilities: enum Items: 'Disabled' 'Enabled' Item0: 'Enabled' Simple mixer control 'Channel Mode',0 Capabilities: enum Items: '2ch' '4ch' '6ch' Item0: '2ch' Simple mixer control 'Digital',0 Capabilities: cvolume penum Capture channels: Front Left - Front Right Limits: Capture 0 - 120 Front Left: Capture 0 [0%] [-30.00dB] Front Right: Capture 0 [0%] [-30.00dB] Simple mixer control 'Internal Mic',0 Capabilities: cswitch cswitch-joined cswitch-exclusive penum Capture exclusive group: 0 Capture channels: Mono Mono: Capture [on] !!Alsactl output !!-------------- --startcollapse-- state.MID { control.1 { iface MIXER name 'Channel Mode' value '2ch' comment { access 'read write' type ENUMERATED count 1 item.0 '2ch' item.1 '4ch' item.2 '6ch' } } control.2 { iface MIXER name 'Headphone Playback Volume' value.0 62 value.1 62 comment { access 'read write' type INTEGER count 2 range '0 - 64' dbmin -6200 dbmax 200 dbvalue.0 0 dbvalue.1 0 } } control.3 { iface MIXER name 'Headphone Playback Switch' value.0 true value.1 true comment { access 'read write' type BOOLEAN count 2 } } control.4 { iface MIXER name 'Surround Playback Volume' value.0 62 value.1 62 comment { access 'read write' type INTEGER count 2 range '0 - 64' dbmin -6200 dbmax 200 dbvalue.0 0 dbvalue.1 0 } } control.5 { iface MIXER name 'Surround Playback Switch' value.0 true value.1 true comment { access 'read write' type BOOLEAN count 2 } } control.6 { iface MIXER name 'Center Playback Volume' value 62 comment { access 'read write' type INTEGER count 1 range '0 - 64' dbmin -6200 dbmax 200 dbvalue.0 0 } } control.7 { iface MIXER name 'LFE Playback Volume' value 62 comment { access 'read write' type INTEGER count 1 range '0 - 64' dbmin -6200 dbmax 200 dbvalue.0 0 } } control.8 { iface MIXER name 'Center Playback Switch' value true comment { access 'read write' type BOOLEAN count 1 } } control.9 { iface MIXER name 'LFE Playback Switch' value true comment { access 'read write' type BOOLEAN count 1 } } control.10 { iface MIXER name 'Speaker Playback Volume' value.0 64 value.1 64 comment { access 'read write' type INTEGER count 2 range '0 - 64' dbmin -6200 dbmax 200 dbvalue.0 200 dbvalue.1 200 } } control.11 { iface MIXER name 'Speaker Playback Switch' value.0 true value.1 true comment { access 'read write' type BOOLEAN count 2 } } control.12 { iface MIXER name 'Mic Playback Volume' value.0 15 value.1 15 comment { access 'read write' type INTEGER count 2 range '0 - 31' dbmin -3450 dbmax 1200 dbvalue.0 -1200 dbvalue.1 -1200 } } control.13 { iface MIXER name 'Mic Playback Switch' value.0 false value.1 false comment { access 'read write' type BOOLEAN count 2 } } control.14 { iface MIXER name 'Mic Playback Volume' index 1 value.0 0 value.1 0 comment { access 'read write' type INTEGER count 2 range '0 - 31' dbmin -3450 dbmax 1200 dbvalue.0 -3450 dbvalue.1 -3450 } } control.15 { iface MIXER name 'Mic Playback Switch' index 1 value.0 false value.1 false comment { access 'read write' type BOOLEAN count 2 } } control.16 { iface MIXER name 'Auto-Mute Mode' value Enabled comment { access 'read write' type ENUMERATED count 1 item.0 Disabled item.1 Enabled } } control.17 { iface MIXER name 'Capture Source' value 'Internal Mic' comment { access 'read write' type ENUMERATED count 1 item.0 Mic item.1 'Mic 1' item.2 'Internal Mic' } } control.18 { iface MIXER name 'Capture Volume' value.0 40 value.1 40 comment { access 'read write' type INTEGER count 2 range '0 - 46' dbmin -1600 dbmax 3000 dbvalue.0 2400 dbvalue.1 2400 } } control.19 { iface MIXER name 'Capture Switch' value.0 true value.1 true comment { access 'read write' type BOOLEAN count 2 } } control.20 { iface MIXER name 'Mic Boost Volume' value.0 0 value.1 0 comment { access 'read write' type INTEGER count 2 range '0 - 3' dbmin 0 dbmax 3000 dbvalue.0 0 dbvalue.1 0 } } control.21 { iface MIXER name 'Mic Boost Volume' index 1 value.0 0 value.1 0 comment { access 'read write' type INTEGER count 2 range '0 - 3' dbmin 0 dbmax 3000 dbvalue.0 0 dbvalue.1 0 } } control.22 { iface MIXER name 'Master Playback Volume' value 64 comment { access 'read write' type INTEGER count 1 range '0 - 64' dbmin -6400 dbmax 0 dbvalue.0 0 } } control.23 { iface MIXER name 'Master Playback Switch' value true comment { access 'read write' type BOOLEAN count 1 } } control.24 { iface CARD name 'Mic Jack' value false comment { access read type BOOLEAN count 1 } } control.25 { iface CARD name 'Mic Jack' index 1 value false comment { access read type BOOLEAN count 1 } } control.26 { iface CARD name 'Internal Mic Phantom Jack' value true comment { access read type BOOLEAN count 1 } } control.27 { iface CARD name 'Headphone Jack' value false comment { access read type BOOLEAN count 1 } } control.28 { iface CARD name 'Speaker Phantom Jack' value true comment { access read type BOOLEAN count 1 } } control.29 { iface MIXER name 'Beep Playback Volume' value.0 0 value.1 0 comment { access 'read write' type INTEGER count 2 range '0 - 31' dbmin -3450 dbmax 1200 dbvalue.0 -3450 dbvalue.1 -3450 } } control.30 { iface MIXER name 'Beep Playback Switch' value.0 false value.1 false comment { access 'read write' type BOOLEAN count 2 } } control.31 { iface PCM name 'Playback Channel Map' value.0 0 value.1 0 comment { access read type INTEGER count 2 range '0 - 36' } } control.32 { iface PCM name 'Capture Channel Map' value.0 0 value.1 0 comment { access read type INTEGER count 2 range '0 - 36' } } control.33 { iface MIXER name 'PCM Playback Volume' value.0 255 value.1 255 comment { access 'read write user' type INTEGER count 2 range '0 - 255' tlv '0000000100000008ffffec1400000014' dbmin -5100 dbmax 0 dbvalue.0 0 dbvalue.1 0 } } control.34 { iface MIXER name 'Digital Capture Volume' value.0 0 value.1 0 comment { access 'read write user' type INTEGER count 2 range '0 - 120' tlv '0000000100000008fffff44800000032' dbmin -3000 dbmax 3000 dbvalue.0 -3000 dbvalue.1 -3000 } } } --endcollapse-- !!All Loaded Modules !!------------------ Module parport_pc ppdev lp parport binfmt_misc fuse ext2 mbcache dm_crypt loop snd_hda_codec_realtek videobuf2_vmalloc videobuf2_memops videobuf2_core videodev media joydev snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm snd_page_alloc snd_seq_dummy snd_seq_oss snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq arc4 coretemp iwldvm kvm_intel mac80211 snd_seq_device kvm snd_timer crc32c_intel ghash_clmulni_intel snd iTCO_wdt iTCO_vendor_support aesni_intel iwlwifi i915 aes_x86_64 ablk_helper mxm_wmi cryptd xts cfg80211 sg lrw gf128mul sr_mod cdrom psmouse drm_kms_helper serio_raw sony_laptop evdev drm rfkill pcspkr video wmi i2c_i801 i2c_algo_bit battery button i2c_core ehci_pci ehci_hcd e1000e intel_ips soundcore acpi_cpufreq mperf ac lpc_ich usbcore mfd_core mei sdhci_pci sdhci ptp mmc_core pps_core usb_common processor btrfs crc32c libcrc32c xor zlib_deflate raid6_pq dm_mod raid0 md_mod sd_mod crc_t10dif ahci libahci microcode thermal thermal_sys libata scsi_mod !!Sysfs Files !!----------- /sys/class/sound/hwC0D0/init_pin_configs: 0x11 0x411111f0 0x12 0x90a60120 0x14 0x90170110 0x15 0x0421101f 0x16 0x411111f0 0x17 0x411111f0 0x18 0x04a1102e 0x19 0x04a11030 0x1a 0x411111f0 0x1b 0x411111f0 0x1c 0x411111f0 0x1d 0x411111f0 0x1e 0x411111f0 0x1f 0x411111f0 /sys/class/sound/hwC0D0/driver_pin_configs: /sys/class/sound/hwC0D0/user_pin_configs: /sys/class/sound/hwC0D0/init_verbs: /sys/class/sound/hwC0D0/hints: !!ALSA/HDA dmesg !!-------------- [ 5.121872] pipe_off wait timed out [ 5.121921] Modules linked in: uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev media joydev snd_hda_intel(O+) snd_hda_codec(O) snd_hwdep(O) snd_pcm_oss(O) snd_mixer_oss(O) snd_pcm(O) snd_page_alloc(O) snd_seq_dummy(O) snd_seq_oss(O) snd_seq_midi(O) snd_seq_midi_event(O) snd_rawmidi(O) snd_seq(O) arc4 coretemp iwldvm kvm_intel mac80211 snd_seq_device(O) kvm snd_timer(O) crc32c_intel ghash_clmulni_intel snd(O) iTCO_wdt iTCO_vendor_support aesni_intel iwlwifi i915(+) aes_x86_64 ablk_helper mxm_wmi cryptd xts cfg80211 sg lrw gf128mul sr_mod cdrom psmouse drm_kms_helper serio_raw sony_laptop evdev drm rfkill pcspkr video wmi i2c_i801 i2c_algo_bit battery button i2c_core ehci_pci ehci_hcd e1000e intel_ips soundcore acpi_cpufreq mperf ac lpc_ich usbcore mfd_core mei sdhci_pci sdhci ptp mmc_core pps_core usb_common processor btrfs crc32c libcrc32c xor zlib_deflate raid6_pq dm_mod raid0 md_mod sd_mod crc_t10dif ahci libahci microcode thermal thermal_sys libata scsi_mod [ 5.121941] Pid: 635, comm: modprobe Tainted: G O 3.9-0.bpo.1-amd64 #1 Debian 3.9.6-1~bpo70+1 -- [ 5.835404] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 [ 5.835752] snd_hda_intel 0000:00:1b.0: irq 45 for MSI/MSI-X [ 5.864320] hda_codec: ALC889: SKU not ready 0x411111f0 [ 5.864675] ALSA hda_auto_parser.c:393 autoconfig: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker [ 5.864681] ALSA hda_auto_parser.c:397 speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 5.864686] ALSA hda_auto_parser.c:401 hp_outs=1 (0x15/0x0/0x0/0x0/0x0) [ 5.864689] ALSA hda_auto_parser.c:402 mono: mono_out=0x0 [ 5.864693] ALSA hda_auto_parser.c:406 inputs: [ 5.864697] ALSA hda_auto_parser.c:410 Mic=0x18 [ 5.864701] ALSA hda_auto_parser.c:410 Mic=0x19 [ 5.864704] ALSA hda_auto_parser.c:410 Internal Mic=0x12 [ 5.864709] ALSA patch_realtek.c:486 realtek: No valid SSID, checking pincfg 0x411111f0 for NID 0x1d [ 5.864713] ALSA patch_realtek.c:569 realtek: Enable default setup for auto mode as fallback [ 5.868644] input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:1b.0/input/input9 [ 5.874177] input: HDA Intel MID Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input10 [ 5.874232] input: HDA Intel MID Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input11 [ 5.874284] input: HDA Intel MID Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input12 [ 6.760494] btrfs: use ssd allocation scheme -- [ 26.166424] pipe_off wait timed out [ 26.166426] Modules linked in: parport_pc ppdev lp parport binfmt_misc fuse ext2 mbcache dm_crypt loop snd_hda_codec_realtek(O) uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev media joydev snd_hda_intel(O) snd_hda_codec(O) snd_hwdep(O) snd_pcm_oss(O) snd_mixer_oss(O) snd_pcm(O) snd_page_alloc(O) snd_seq_dummy(O) snd_seq_oss(O) snd_seq_midi(O) snd_seq_midi_event(O) snd_rawmidi(O) snd_seq(O) arc4 coretemp iwldvm kvm_intel mac80211 snd_seq_device(O) kvm snd_timer(O) crc32c_intel ghash_clmulni_intel snd(O) iTCO_wdt iTCO_vendor_support aesni_intel iwlwifi i915 aes_x86_64 ablk_helper mxm_wmi cryptd xts cfg80211 sg lrw gf128mul sr_mod cdrom psmouse drm_kms_helper serio_raw sony_laptop evdev drm rfkill pcspkr video wmi i2c_i801 i2c_algo_bit battery button i2c_core ehci_pci ehci_hcd e1000e intel_ips soundcore acpi_cpufreq mperf ac lpc_ich usbcore mfd_core mei sdhci_pci sdhci ptp mmc_core pps_core usb_common processor btrfs crc32c libcrc32c xor zlib_deflate raid6_pq dm_mod raid0 md_mod sd_mod crc_t10dif ahci libahci microcode thermal thermal_sys libata scsi_mod [ 26.166527] Pid: 4157, comm: Xorg Tainted: G W O 3.9-0.bpo.1-amd64 #1 Debian 3.9.6-1~bpo70+1

4 38

[alsa-devel] Fwd: Re: Realtek ALC889: HDA Intel and kernel 3.1 gives choppy sound (again)
by Colomban Wendling 18 Sep '13

18 Sep '13

Here's my initial mail, but with gzipped outputs. Regards, Colomban -------- Message original -------- Sujet: Re: [alsa-devel] Realtek ALC889: HDA Intel and kernel 3.1 gives choppy sound (again) Date : Thu, 10 Nov 2011 02:11:17 +0100 De : Colomban Wendling <lists.ban(a)herbesfolles.org> Pour : Takashi Iwai <tiwai(a)suse.de> Copie à : alsa-devel(a)alsa-project.org Hi again, and sorry for the delay. Le 08/11/2011 07:32, Takashi Iwai a écrit : > At Mon, 07 Nov 2011 23:45:40 +0100, > Colomban Wendling wrote: >> >> Hi, >> >> Back to 3.0, the sound on my soundcard [1] started to be choppy, I >> reported it [2] and it got fixed (thanks to Takashi Iwai!). >> >> However, the story repeated with 3.1 (and probably 3.0.8 or before [3]): >> I've got similar choppy sound again. >> >> I bisected the few commits that happened on >> sound/pci/hda/patch_realtek.c, and finally found the villain: >> >> "8974bd51 ALSA: hda/realtek - Fix auto-mute with HP+LO configuration" >> >> Reverting it from v3.1 fixes the problem. > > Does it? Very weird. This patch has nothing to do with the HD-audio > controller side but purely a codec change. Yep, I just check once again and it really fixes the problem here. >> master (94956ee) also suffers of the problem, but I couldn't test >> without that commit because reverting it fails, too much changes happened. > > Did you try to pass position_fix=1 (or 2) option? > Also, passing enable_msi=0 (or 1) may change anything? I just tried with the 3 kernels: * vanilla v3.1 * vanilla 3.2-rc1 (master at 1ea6b8f) * v3.1 with 8974bd51 reverted and none of the option changed anything: both vanilla always failed, the third always succeeded. Though, I haven't combined the options, just tried each at once. > In anyway, please give alsa-info.sh output again with the fresh > kernel. Run it with --no-upload option and attach the output. Here it is, for the 3 kernels cited above. Regards, Colomban

4 14

[alsa-devel] [PATCH] ASoC: codecs: da9055: Update driver name to fix breakage due to pmic driver with same name
by Ashish Chavan 13 Sep '13

13 Sep '13

This patch updates i2c driver name and device id of da9055 codec driver. DA9055 is a PMIC + CODEC and currently, the corresponding PMIC driver also registers itself with the same name as codec, i.e. "da9055". Because of this the codec driver was broken. Now codec driver uses "da9055-codec" as driver name instead of "da9055". Signed-off-by: Ashish Chavan <ashish.chavan(a)kpitcummins.com> Signed-off-by: David Dajun Chen <david.chen(a)diasemi.com> --- sound/soc/codecs/da9055.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/da9055.c b/sound/soc/codecs/da9055.c index 2e1bf5d..e146f68 100644 --- a/sound/soc/codecs/da9055.c +++ b/sound/soc/codecs/da9055.c @@ -1544,7 +1544,7 @@ static int da9055_remove(struct i2c_client *client) } static const struct i2c_device_id da9055_i2c_id[] = { - { "da9055", 0 }, + { "da9055-codec", 0 }, { } }; MODULE_DEVICE_TABLE(i2c, da9055_i2c_id); @@ -1552,7 +1552,7 @@ MODULE_DEVICE_TABLE(i2c, da9055_i2c_id); /* I2C codec control layer */ static struct i2c_driver da9055_i2c_driver = { .driver = { - .name = "da9055", + .name = "da9055-codec", .owner = THIS_MODULE, }, .probe = da9055_i2c_probe, -- 1.7.1

3 29