- 14 Jun, 2017 8 commits
-
-
Takashi Sakamoto authored
SNDRV_PCM_IOCTL1_GSTATE was firstly introduced in v0.9.0, however never be used and the purpose is missing. This commit removes the long-abandoned command, bye. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Sakamoto authored
Drivers can implement 'struct snd_pcm_ops.ioctl' to handle some requests from ALSA PCM core. These requests are internal purpose in kernel land. Usually common set of operations are used for it. SNDRV_PCM_IOCTL1_INFO is one of the requests. According to code comment, it has been obsoleted in the old days. We can see old releases in ftp.alsa-project.org. The command was firstly introduced in v0.5.0 release as SND_PCM_IOCTL1_INFO, to allow drivers to fill data of 'struct snd_pcm_channel_info' type. In v0.9.0 release, this was obsoleted by the other commands for ioctl(2) such as SNDRV_PCM_IOCTL_CHANNEL_INFO. This commit removes the long-abandoned command, bye. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
We call ack callback whenever appl_ptr gets updated via pcm_lib_apply_appl_ptr(). There are various code paths to call this function. A part of them are for read/write/forward/rewind, where the appl_ptr is always changed and thus the call of ack is mandatory. OTOH, another part of code paths are from the explicit user call, e.g. via SYNC_PTR ioctl. There, we may receive the same appl_ptr value, and in such a case, calling ack is obviously superfluous. This patch adds the check of the given appl_ptr value, and returns immediately if it's no real update. Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
Just a code cleanup. Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
Calling PREPARE ioctl to the stream in either PAUSED or SUSPENDED state may confuse some drivers that don't handle the state properly. Instead of fixing each driver, PCM core should take care of the proper state change before actually trying to (re-)prepare the stream. Namely, when the stream is in PAUSED state, it triggers PAUSE_RELEASE, and when in SUSPENDED state, it triggers STOP, before calling prepare callbacks. Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
So far, the PCM core refuses DROP ioctl when the stream in the suspended state. This was basically to avoid the invalid state change *during* the suspend. But since we protect the power change globally in the common PCM ioctl caller side, it's guaranteed that snd_pcm_drop() is called at the right power state. So we can assume that the drop of stream is safe immediately after SUSPENDED state. Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
All PCM common ioctls should run only in the powered up state, but currently only a few ioctls do the proper snd_power_lock() and snd_power_wait() invocations. Instead of adding to each place, do it commonly in the caller side, so that all these ioctls are assured to be operated at the power up state. Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
Use snd_pcm_action_lock_irq() helper instead of open coding. No functional change. Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 13 Jun, 2017 1 commit
-
-
Takashi Iwai authored
-
- 12 Jun, 2017 4 commits
-
-
Takashi Sakamoto authored
As long as I know, in userspace, '%c' format on printing format for tracepoint is replaced with '>c<' by existent tracing program; i.g. 'perf-trace' and 'trace-cmd'. This is inconvenient. This commit replaces the format with '%s'. The length of letters in the format string is not changed, thus this commit doesn't increase object size. In theory, I should work for improvements of these tracing programs, but here I'd like to save my time to work for the other projects. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Sakamoto authored
In design of ALSA PCM core, status and control data for runtime of ALSA PCM substream are shared between kernel/user spaces by page frame mapping with read-only attribute. Both of hardware-side and application-side position on PCM buffer are maintained as a part of the status data. In a view of ALSA PCM application, these two positions can be updated by executing ioctl(2) with some commands. There's an event of tracepoint for hardware-side position; 'hwptr'. On the other hand, no events for application-side position. This commit adds a new event for this purpose; 'applptr'. When the application-side position is changed in kernel space, this event is probed with useful information for developers. I note that the event is not probed for all of ALSA PCM applications, When applications are written by read/write programming scenario, the event is surely probed. The applications execute ioctl(2) with SNDRV_PCM_IOCTL_[READ|WRITE][N/I]_FRAMES to read/write any PCM frame, then ALSA PCM core updates the application-side position in kernel land. However, when applications are written by mmap programming scenario, if maintaining the application side position in kernel space accurately, applications should voluntarily execute ioctl(2) with SNDRV_PCM_IOCTL_SYNC_PTR to commit the number of handled PCM frames. If not voluntarily, the application-side position is not changed, thus the added event is not probed. There's a loophole, using architectures to which ALSA PCM core judges non cache coherent. In this case, the status and control data is not mapped into processe's VMA for any applications. Userland library, alsa-lib, is programmed for this case. It executes ioctl(2) with SNDRV_PCM_IOCTL_SYNC_PTR command every time to requiring the status and control data. ARM is such an architecture. Below is an example with serial sound interface (ssi) on i.mx6 quad core SoC. I use v4.1 kernel released by fsl-community with patches from VIA Tech. Inc. for VAB820, and my backport patches for relevant features for this patchset. I use Ubuntu 17.04 from ports.ubuntu.com as user land for armhf architecture. $ aplay -v -M -D hw:imx6vab820sgtl5,0 /dev/urandom -f S16_LE -r 48000 --period-size=128 --buffer-size=256 Playing raw data '/dev/urandom' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono Hardware PCM card 0 'imx6-vab820-sgtl5000' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : MMAP_INTERLEAVED format : S16_LE subformat : STD channels : 1 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 256 period_size : 128 period_time : 2666 tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1 avail_min : 128 period_event : 0 start_threshold : 256 stop_threshold : 256 silence_threshold: 0 silence_size : 0 boundary : 1073741824 appl_ptr : 0 hw_ptr : 0 mmap_area[0] = 0x76f98000,0,16 (16) $ trace-cmd record -e snd_pcm:hwptr -e snd_pcm:applptr $ trace-cmd report ... 60.208495: applptr: pcmC0D0p/sub0: prev=1792, curr=1792, avail=0, period=128, buf=256 60.208633: applptr: pcmC0D0p/sub0: prev=1792, curr=1792, avail=0, period=128, buf=256 60.210022: hwptr: pcmC0D0p/sub0: IRQ: pos=128, old=1536, base=1536, period=128, buf=256 60.210202: applptr: pcmC0D0p/sub0: prev=1792, curr=1792, avail=128, period=128, buf=256 60.210344: hwptr: pcmC0D0p/sub0: POS: pos=128, old=1664, base=1536, period=128, buf=256 60.210348: applptr: pcmC0D0p/sub0: prev=1792, curr=1792, avail=128, period=128, buf=256 60.210486: applptr: pcmC0D0p/sub0: prev=1792, curr=1792, avail=128, period=128, buf=256 60.210626: applptr: pcmC0D0p/sub0: prev=1792, curr=1920, avail=0, period=128, buf=256 60.211002: applptr: pcmC0D0p/sub0: prev=1920, curr=1920, avail=0, period=128, buf=256 60.211142: hwptr: pcmC0D0p/sub0: POS: pos=128, old=1664, base=1536, period=128, buf=256 60.211146: applptr: pcmC0D0p/sub0: prev=1920, curr=1920, avail=0, period=128, buf=256 60.211287: applptr: pcmC0D0p/sub0: prev=1920, curr=1920, avail=0, period=128, buf=256 60.212690: hwptr: pcmC0D0p/sub0: IRQ: pos=0, old=1664, base=1536, period=128, buf=256 60.212866: applptr: pcmC0D0p/sub0: prev=1920, curr=1920, avail=128, period=128, buf=256 60.212999: hwptr: pcmC0D0p/sub0: POS: pos=0, old=1792, base=1792, period=128, buf=256 60.213003: applptr: pcmC0D0p/sub0: prev=1920, curr=1920, avail=128, period=128, buf=256 60.213135: applptr: pcmC0D0p/sub0: prev=1920, curr=1920, avail=128, period=128, buf=256 60.213276: applptr: pcmC0D0p/sub0: prev=1920, curr=2048, avail=0, period=128, buf=256 60.213654: applptr: pcmC0D0p/sub0: prev=2048, curr=2048, avail=0, period=128, buf=256 60.213796: hwptr: pcmC0D0p/sub0: POS: pos=0, old=1792, base=1792, period=128, buf=256 60.213800: applptr: pcmC0D0p/sub0: prev=2048, curr=2048, avail=0, period=128, buf=256 60.213937: applptr: pcmC0D0p/sub0: prev=2048, curr=2048, avail=0, period=128, buf=256 60.215356: hwptr: pcmC0D0p/sub0: IRQ: pos=128, old=1792, base=1792, period=128, buf=256 60.215542: applptr: pcmC0D0p/sub0: prev=2048, curr=2048, avail=128, period=128, buf=256 60.215679: hwptr: pcmC0D0p/sub0: POS: pos=128, old=1920, base=1792, period=128, buf=256 60.215683: applptr: pcmC0D0p/sub0: prev=2048, curr=2048, avail=128, period=128, buf=256 60.215813: applptr: pcmC0D0p/sub0: prev=2048, curr=2048, avail=128, period=128, buf=256 60.215947: applptr: pcmC0D0p/sub0: prev=2048, curr=2176, avail=0, period=128, buf=256 ... We can surely see 'applptr' event is probed even if the application run for mmap programming scenario ('-M' option and 'hw' plugin). Below is a result of strace: 02:44:15.886382 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0 02:44:15.887203 poll([{fd=4, events=POLLOUT|POLLERR|POLLNVAL}], 1, -1) = 1 ([{fd=4, revents=POLLOUT}]) 02:44:15.887471 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0 02:44:15.887637 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0 02:44:15.887805 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0 02:44:15.887969 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0 02:44:15.888132 read(3, "..."..., 256) = 256 02:44:15.889040 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0 02:44:15.889221 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0 02:44:15.889431 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0 02:44:15.889606 poll([{fd=4, events=POLLOUT|POLLERR|POLLNVAL}], 1, -1) = 1 ([{fd=4, revents=POLLOUT}]) 02:44:15.889833 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0 02:44:15.889998 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0 02:44:15.890164 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0 02:44:15.891048 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0 02:44:15.891228 read(3, "..."..., 256) = 256 02:44:15.891497 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0 02:44:15.891661 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0 02:44:15.891829 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0 02:44:15.891991 poll([{fd=4, events=POLLOUT|POLLERR|POLLNVAL}], 1, -1) = 1 ([{fd=4, revents=POLLOUT}]) 02:44:15.893007 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0 We can see 7 calls of ioctl(2) with SNDRV_PCM_IOCTL_SYNC_PTR per loop with call of poll(2). 128 PCM frames are transferred per loop of one poll(2), because the PCM substream is configured with S16_LE format and 1 channel (2 byte * 1 * 128 = 256 bytes). This equals to the size of period of PCM buffer. Comparing to the probed data, one of the 7 calls of ioctl(2) is actually used to commit the number of copied PCM frames to kernel space. The other calls are just used to check runtime status of PCM substream; e.g. XRUN. The tracepoint event is useful to investigate this case. I note that below modules are related to the above sample. * snd-soc-dummy.ko * snd-soc-imx-sgtl5000.ko * snd-soc-fsl-ssi.ko * snd-soc-imx-pcm-dma.ko * snd-soc-sgtl5000.ko My additional note is lock acquisition. The event is probed under acquiring PCM stream lock. This means that calculation in the event is free from any hardware events. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Sakamoto authored
In a series of recent work, ALSA PCM core got some arrangements to handle application-side position on PCM buffer. However, relevant codes still disperse to two translation units This commit unifies these codes into a helper function. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
Many drivers bind the sequencer stuff in off-load by another driver module, so that it's loaded only on demand. In the current code, this mechanism doesn't work when the driver is built-in while the sequencer is module. We check with IS_REACHABLE() and enable only when the sequencer is in the same level of build. However, this is basically a overshoot. The binder code (snd-seq-device) is an individual module from the sequencer core (snd-seq), and we just have to make the former a built-in while keeping the latter a module for allowing the scenario like the above. This patch achieves that by rewriting Kconfig slightly. Now, a driver that provides the manual sequencer device binding should select CONFIG_SND_SEQ_DEVICE in a way as select SND_SEQ_DEVICE if SND_SEQUENCER != n Note that the "!=n" is needed here to avoid the influence of the sequencer core is module while the driver is built-in. Also, since rawmidi.o may be linked with snd_seq_device.o when built-in, we have to shuffle the code to make the linker happy. (the kernel linker isn't smart enough yet to handle such a case.) That is, snd_seq_device.c is moved to sound/core from sound/core/seq, as well as Makefile. Last but not least, the patch replaces the code using IS_REACHABLE() with IS_ENABLED(), since now the condition meets always when enabled. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 11 Jun, 2017 2 commits
-
-
Takashi Sakamoto authored
At present, trace events are probed even if corresponding parameter is not actually changed. This is inconvenient. This commit improves the behaviour. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Sakamoto authored
When refining mask/interval parameters, helper functions can return error code. This error is not handled immediately. This seems to return parameters to userspace applications in its meddle of processing. However, in general, when receiving error from system calls, the application might not handle argument buffer. It's reasonable to judge the above design as superfluity. This commit handles the error immediately. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 09 Jun, 2017 25 commits
-
-
Takashi Iwai authored
Instead of the non-standard way to enable the build of snd-emux-synth module inside Makefile, rewrite Kconfig to select the item explicitly from each driver (sbawe and emu10k1). This is the standard way. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
This is a slightly intensive rewrite of Kconfig and Makefile about ALSA sequencer stuff. The first major change is that the kconfig items for the sequencer are moved to sound/core/seq/Kconfig. OK, that's easy. The substantial change is that, instead of hackish top-level module selection in Makefile, we define a Kconfig item for each sequencer module. The driver that requires such sequencer components select exclusively the kconfig items. This is more straightforward and standard way. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
Currently OSS sequencer emulation is tied with ALSA sequencer core, both are built in the same level; i.e. when CONFIG_SND_SEQUENCER=y, the OSS sequencer emulation is also always built-in, even though the functionality can be built as an individual module. This patch changes the rule and allows users to build snd-seq-oss module while others are built-in. Essentially, it's just a few simple changes in Kconfig and Makefile. Some driver codes like opl3 need to convert from the simple ifdef to IS_ENABLED(). But that's all. You might wonder how about the dependency: right, it can be messy, but it still works. Since we rewrote the sequencer binding with the standard bus, the driver can be bound at any time on demand. So, the synthesizer driver module can be loaded individually from the OSS emulation core before/after it. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
Currently CONFIG_SND_OSSEMUL is selected by each config like CONFIG_SND_PCM_OSS. But, as see in the raw MIDI code that is built conditionally with CONFIG_SND_OSSEMUL, we should rather make CONFIG_SND_OSSEMUL user-selectable as the top kconfig item, and leave the rest depending on it. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Sakamoto authored
Use the same print format of snd_pcm_debug_name() for userspace tracing program. Suggested-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Sakamoto authored
Results of ioctl(2) with SNDRV_PCM_IOCTL_HW_REFINE and SNDRV_PCM_IOCTL_HW_PARAMS are different, because the latter has single value for several parameters; e.g. channels of PCM substream. Selection of the single value is done independently of application of constraints. It's helpful for developers to trace the selection process. This commit adds tracepoints to snd_pcm_hw_params_choose() for the purpose. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Sakamoto authored
As of v4.12, snd_pcm_hw_params_choose() is just called in a process context of ioctl(2) with SNDRV_PCM_IOCTL_HW_PARAMS. The function locates in a different file, which has no tracepoints. This commit moves the function to a file with the tracepoints for later commit. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
snd_pcm_hw_constraint_list(), *_ratnums() and *_ratdens() receive the const pointers. Constify the corresponding static objects for better hardening. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
snd_pcm_hw_constraint_list(), *_ratnums() and *_ratdens() receive the const pointers. Constify the corresponding static objects for better hardening. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
snd_pcm_hw_constraint_list(), *_ratnums() and *_ratdens() receive the const pointers. Constify the corresponding static objects for better hardening. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
snd_pcm_hw_constraint_list(), *_ratnums() and *_ratdens() receive the const pointers. Constify the corresponding static objects for better hardening. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
snd_pcm_hw_constraint_list(), *_ratnums() and *_ratdens() receive the const pointers. Constify the corresponding static objects for better hardening. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
snd_pcm_hw_constraint_list(), *_ratnums() and *_ratdens() receive the const pointers. Constify the corresponding static objects for better hardening. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
snd_pcm_hw_constraint_list(), *_ratnums() and *_ratdens() receive the const pointers. Constify the corresponding static objects for better hardening. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
snd_pcm_hw_constraint_list(), *_ratnums() and *_ratdens() receive the const pointers. Constify the corresponding static objects for better hardening. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
snd_pcm_hw_constraint_list(), *_ratnums() and *_ratdens() receive the const pointers. Constify the corresponding static objects for better hardening. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
snd_pcm_hw_constraint_list(), *_ratnums() and *_ratdens() receive the const pointers. Constify the corresponding static objects for better hardening. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
snd_pcm_hw_constraint_list(), *_ratnums() and *_ratdens() receive the const pointers. Constify the corresponding static objects for better hardening. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
snd_pcm_hw_constraint_list(), *_ratnums() and *_ratdens() receive the const pointers. Constify the corresponding static objects for better hardening. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
snd_pcm_hw_constraint_list(), *_ratnums() and *_ratdens() receive the const pointers. Constify the corresponding static objects for better hardening. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
snd_pcm_hw_constraint_list(), *_ratnums() and *_ratdens() receive the const pointers. Constify the corresponding static objects for better hardening. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
snd_pcm_hw_constraint_list(), *_ratnums() and *_ratdens() receive the const pointers. Constify the corresponding static objects for better hardening. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
snd_pcm_hw_constraint_list(), *_ratnums() and *_ratdens() receive the const pointers. Constify the corresponding static objects for better hardening. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
snd_pcm_hw_constraint_list(), *_ratnums() and *_ratdens() receive the const pointers. Constify the corresponding static objects for better hardening. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
snd_pcm_hw_constraint_list(), *_ratnums() and *_ratdens() receive the const pointers. Constify the corresponding static objects for better hardening. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-