summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-06-26Merge branch 'for-next' into for-linusTakashi Iwai
Pull the 6.5-devel branch for upstreaming. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-26ALSA: hda/realtek: Enable mute/micmute LEDs and limit mic boost on EliteBookAndy Chi
On HP EliteBook 835/845/845W G10, the audio LEDs can be enabled by ALC285_FIXUP_HP_MUTE_LED. So use it accordingly. Signed-off-by: Andy Chi <andy.chi@canonical.com> Cc: <stable@vger.kernel.org> Fixes: 3e10f6ca76c4 ("ALSA: hda/realtek: Add quirk for HP EliteBook G10 laptops") Link: https://lore.kernel.org/r/20230626130301.301712-1-andy.chi@canonical.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-25ASoC: hdmi-codec: fix channel info for compressed formatsMatthias Reichl
According to CTA 861 the channel/speaker allocation info in the audio infoframe only applies to uncompressed (PCM) audio streams. The channel count info should indicate the number of channels in the transmitted audio, which usually won't match the number of channels used to transmit the compressed bitstream. Some devices (eg some Sony TVs) will refuse to decode compressed audio if these values are not set correctly. To fix this we can simply set the channel count to 0 (which means "refer to stream header") and set the channel/speaker allocation to 0 as well (which would mean stereo FL/FR for PCM, a safe value all sinks will support) when transmitting compressed audio. Signed-off-by: Matthias Reichl <hias@horus.com> Link: https://lore.kernel.org/r/20230624165232.5751-1-hias@horus.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-25ALSA: pcm: fix ELD constraints for (E)AC3, DTS(-HD) and MLP formatsMatthias Reichl
The SADs of compressed formats contain the channel and sample rate info of the audio data inside the compressed stream, but when building constraints we must use the rates and channels used to transport the compressed streams. eg 48kHz 6ch EAC3 needs to be transmitted as a 2ch 192kHz stream. This patch fixes the constraints for the common AC3 and DTS formats, the constraints for the less common MPEG, DSD etc formats are copied directly from the info in the SADs as before as I don't have the specs and equipment to test those. Signed-off-by: Matthias Reichl <hias@horus.com> Link: https://lore.kernel.org/r/20230624165216.5719-1-hias@horus.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-23Merge branch 'topic/midi20' into for-nextTakashi Iwai
Pull one more API update for UMP core. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-23ALSA: ump: Export MIDI1 / UMP conversion helpersTakashi Iwai
Yet more preliminary work for the upcoming USB gadget support. Now export the helpers to convert between legacy MIDI1 and UMP data for handling the MIDI 1.0 USB interface. The header file is moved to include/sound. The API functions are slightly changed, so that they can be used without the direct access to snd_ump object. The allocation is done in ump.c itself as it's a simple kcalloc(). Link: https://lore.kernel.org/r/20230623075530.10976-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-21ALSA: hda/realtek: Add quirks for ROG ALLY CS35l41 audioMatthew Anderson
This requires a patched ACPI table or a firmware from ASUS to work because the system does not come with the _DSD field for the CSC3551. Link: https://bugzilla.kernel.org/show_bug.cgi?id=217550 Signed-off-by: Matthew Anderson <ruinairas1992@gmail.com> Tested-by: Philip Mueller <philm@manjaro.org> Link: https://lore.kernel.org/r/20230621161714.9442-1-ruinairas1992@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-21Merge tag 'asoc-fix-v6.4-rc7' of ↵Takashi Iwai
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fix for v6.4 A fix for a typoed iterator in the Intel Soundwire driver, fairly simple on inspection though not reviewed by Intel.
2023-06-21ALSA: hda/realtek: Add quirk for ASUS ROG GV601VLuke D. Jones
Adds the required quirk to enable the Cirrus amp and correct pins on the ASUS ROG GV601V series. While this works if the related _DSD properties are made available, these aren't included in the ACPI of these laptops (yet). Signed-off-by: Luke D. Jones <luke@ljones.dev> Link: https://lore.kernel.org/r/20230621085715.5382-1-luke@ljones.dev Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-21Merge branch 'topic/midi20' into for-nextTakashi Iwai
This is a small patch set to change the UMP core for the upcoming gadget driver support. Basically exporting a couple of helper functions and adding a flag to suppress the internal UMP handling. No functional changes by those alone. Link: https://lore.kernel.org/r/20230621110241.4751-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-21ALSA: ump: Export snd_ump_receive_ump_val()Takashi Iwai
This is another preliminary patch for USB MIDI 2.0 gadget driver. Export the currently local snd_ump_receive_ump_val(). It can be used by the gadget driver for processing the UMP data. Link: https://lore.kernel.org/r/20230621110241.4751-4-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-21ALSA: ump: Add no_process_stream flagTakashi Iwai
This is another preliminary patch for USB MIDI 2.0 gadget driver. Add a new flag, no_process_stream, to snd_ump for suppressing the UMP Stream message handling in UMP core. Link: https://lore.kernel.org/r/20230621110241.4751-3-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-21ALSA: ump: Add helper to change MIDI protocolTakashi Iwai
This is a preliminary patch for MIDI 2.0 USB gadget driver. Export a new helper to allow changing the current MIDI protocol from the outside. Link: https://lore.kernel.org/r/20230621110241.4751-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-21sound: make all 'class' structures constIvan Orlov
Now that the driver core allows for struct class to be in read-only memory, making all 'class' structures to be declared at build time placing them into read-only memory, instead of having to be dynamically allocated at load time. Cc: Jaroslav Kysela <perex@perex.cz> Cc: Takashi Iwai <tiwai@suse.com> Cc: Ivan Orlov <ivan.orlov0322@gmail.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Geoff Levand <geoff@infradead.org> Cc: Thierry Reding <treding@nvidia.com> Cc: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> Cc: alsa-devel@alsa-project.org Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ivan Orlov <ivan.orlov0322@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20230620175633.641141-2-gregkh@linuxfoundation.org Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-21ALSA: compress: allow setting codec params after next trackSrinivas Kandagatla
For gapless playback it is possible that each track can have different codec profile with same decoder, for example we have WMA album, we may have different tracks as WMA v9, WMA v10 and so on Or if DSP's like QDSP have abililty to switch decoders on single stream for each track, then this call could be used to set new codec parameters. Existing code does not allow to change this profile while doing gapless playback. Reuse existing SNDRV_COMPRESS_SET_PARAMS to set this new track params along some additional checks to enforce proper state machine. With this new changes now the user can call SNDRV_COMPRESS_SET_PARAMS anytime after setting next track and additional check in write should also ensure that params are set before writing new data. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Acked-by: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20230619092805.21649-1-srinivas.kandagatla@linaro.org Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-19ALSA: hda/realtek: Add quirk for ASUS ROG G634ZLuke D. Jones
Adds the required quirk to enable the Cirrus amp and correct pins on the ASUS ROG G634Z series. While this works if the related _DSD properties are made available, these aren't included in the ACPI of these laptops (yet). Signed-off-by: Luke D. Jones <luke@ljones.dev> Link: https://lore.kernel.org/r/20230619060320.1336455-1-luke@ljones.dev Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-19ASoC: intel: sof_sdw: Fixup typo in device link checkingCharles Keepax
The loop checking for multiple different devices on a single sdw link contains a typo accidentally using i twice instead of j. Correct to the correct index variable. Fixes: dc5a3e60a4b5 ("ASoC: Intel: sof_sdw: append codec type to dai link name") Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230614142116.1059677-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-16Merge tag 'asoc-fix-v6.4-rc6-2' of ↵Takashi Iwai
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v6.4 A couple more fixes for v6.4, one fixing a misleading error log and another stopping us seeing spurious failures setting the master volume on some Tegra systems introduced by a change to how we calculate delay times.
2023-06-16ALSA: usb-audio: Add quirk flag for HEM devices to enable native DSD playbackLukasz Tyl
This commit adds new DEVICE_FLG with QUIRK_FLAG_DSD_RAW and Vendor Id for HEM devices which supports native DSD. Prior to this change Linux kernel was not enabling native DSD playback for HEM devices, and as a result, DSD audio was being converted to PCM "on the fly". HEM devices, when connected to the system, would only play audio in PCM format, even if the source material was in DSD format. With the addition of new VENDOR_FLG in the quircks.c file, the devices are now correctly recognized, and raw DSD data is transmitted to the device, allowing for native DSD playback. Signed-off-by: Lukasz Tyl <ltyl@hem-e.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20230614122524.30271-1-ltyl@hem-e.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-16ALSA: usb-audio: Fix broken resume due to UAC3 power stateTakashi Iwai
As reported in the bugzilla below, the PM resume of a UAC3 device may fail due to the incomplete power state change, stuck at D1. The reason is that the driver expects the full D0 power state change only at hw_params, while the normal PCM resume procedure doesn't call hw_params. For fixing the bug, we add the same power state update to D0 at the prepare callback, which is certainly called by the resume procedure. Note that, with this change, the power state change in the hw_params becomes almost redundant, since snd_usb_hw_params() doesn't touch the parameters (at least it tires so). But dropping it is still a bit risky (e.g. we have the media-driver binding), so I leave the D0 power state change in snd_usb_hw_params() as is for now. Fixes: a0a4959eb4e9 ("ALSA: usb-audio: Operate UAC3 Power Domains in PCM callbacks") Cc: <stable@vger.kernel.org> Link: https://bugzilla.kernel.org/show_bug.cgi?id=217539 Link: https://lore.kernel.org/r/20230612132818.29486-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-16ALSA: seq: oss: Fix racy open/close of MIDI devicesTakashi Iwai
Although snd_seq_oss_midi_open() and snd_seq_oss_midi_close() can be called concurrently from different code paths, we have no proper data protection against races. Introduce open_mutex to each seq_oss_midi object for avoiding the races. Reported-by: "Gong, Sishuai" <sishuai@purdue.edu> Closes: https://lore.kernel.org/r/7DC9AF71-F481-4ABA-955F-76C535661E33@purdue.edu Link: https://lore.kernel.org/r/20230612125533.27461-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-15ALSA: ac97: Fix possible NULL dereference in snd_ac97_mixerSu Hui
smatch error: sound/pci/ac97/ac97_codec.c:2354 snd_ac97_mixer() error: we previously assumed 'rac97' could be null (see line 2072) remove redundant assignment, return error if rac97 is NULL. Fixes: da3cec35dd3c ("ALSA: Kill snd_assert() in sound/pci/*") Signed-off-by: Su Hui <suhui@nfschina.com> Link: https://lore.kernel.org/r/20230615021732.1972194-1-suhui@nfschina.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-13ASoC: tegra: Fix Master Volume ControlJon Hunter
Commit 3ed2b549b39f ("ALSA: pcm: fix wait_time calculations") corrected the PCM wait_time calculations and in doing so reduced the calculated wait_time. This exposed an issue with the Tegra Master Volume Control (MVC) device where the reduced wait_time caused the MVC to fail. For now fix this by setting the default wait_time for Tegra to be 500ms. Fixes: 3ed2b549b39f ("ALSA: pcm: fix wait_time calculations") Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/20230613093453.13927-1-jonathanh@nvidia.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-13ALSA: emu10k1: actually show some S/PDIF status in /proc for E-MU cardsOswald Buddenhagen
The file is called spdif-in, but we abused it to show only sample rates from various sources. Rectify it as far as possible (the FPGA doesn't give us a lot of information). Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230612191325.1315854-10-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-13ALSA: emu10k1: add support for 12 kHz capture on AudigyOswald Buddenhagen
Fixes a tentative FIXME. Because we can. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230612191325.1315854-9-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-13ALSA: emu10k1: fix timer for E-MU cards at 44.1 kHz word clockOswald Buddenhagen
The timer was presuming a fixed 48 kHz word clock, like the rest of the code. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230612191325.1315854-8-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-13ALSA: timer: minimize open-coded access to hw.resolutionOswald Buddenhagen
Some info-querying code still used hw.resolution directly instead of calling snd_timer_hw_resolution(), thus missing a possible hw.c_resolution callback. This patch rectifies that. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230612191325.1315854-7-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-13ALSA: emu10k1: fix synthesizer pitch for E-MU cards at 44.1 kHzOswald Buddenhagen
This is only a very partial fix - the frequency-dependent envelope & LFO register values aren't adjusted. But I'm not sure they were even correct at 48 kHz to start with, as most of them are precalculated by common code which assumes an EMU8K-specific 44.1 kHz word clock, and it seems somewhat unlikely that the hardware's register interpretation was adjusted to compensate for the different word clock. In any case I'm not going to spend time on fixing that, as this code is unlikely to be actually used by anyone today. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230612191325.1315854-6-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-13ALSA: emu10k1: fix sample rates for E-MU cards at 44.1 kHz word clockOswald Buddenhagen
Now that we know the actual word clock, we can: - Put the resulting rate into the hardware info - At 44.1 kHz word clock shift the rate for the pitch calculations, which presume a 48 kHz word clock Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230612191325.1315854-5-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-13ALSA: emu10k1: query rate of external clock sources on E-MU cardsOswald Buddenhagen
The value isn't used yet; the subsequent commits will do that. This ignores the existence of rates above 48 kHz, which is fine, as the hardware will just switch to the fallback clock source when fed with a rate which is incompatible with the base clock multiplier, which currently is always x1. The sample rate display in /proc spdif-in is adjusted to reflect our understanding of the input rates. This is tested only with an 0404b card without sync card, so there is a lot of room for improvement. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230612191325.1315854-4-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-13ALSA: emu10k1: make available E-MU clock sources card-specificOswald Buddenhagen
The actually available clock sources depend on the available audio input ports and dedicated clock input ports. This includes refactoring the code to be data-driven to remain manageable. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230612191325.1315854-3-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-13ALSA: emu10k1: split off E-MU fallback clock from clock sourceOswald Buddenhagen
So far, we set the fallback as a side effect of setting the source. But the fallback makes no sense at all when an internal clock is selected. Defaulting to 48k for S/PDIF & ADAT makes sense, but as that is the global default and we're not changing it automatically any more, it's just fine to leave it entirely to the explicit setting. This changes the name of the pre-existing control to something more appropriate (regardless of the split), so users will need to adjust their mixer settings. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230612191325.1315854-2-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-13Merge branch 'topic/midi20' into for-nextTakashi Iwai
As the updated MIDI 2.0 spec has been published freshly, this is a catch up to add the support for new specs, especially UMP v1.1 features, on Linux kernel. The new UMP v1.1 introduced the concept of Function Blocks (FB), which is a kind of superset of USB MIDI 2.0 Group Terminal Blocks (GTB). The patch set adds the support for FB as the primary information source while keeping the parse of GTB as fallback. Also UMP v1.1 supports the groupless messages, the protocol switch, static FBs, and other new fundamental features, and those are supported as well. Link: https://www.midi.org/midi-articles/details-about-midi-2-0-midi-ci-profiles-and-property-exchange Link: https://lore.kernel.org/r/20230612081054.17200-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-12ALSA: docs: Update MIDI 2.0 documentation for UMP 1.1 enhancementTakashi Iwai
There have been a few enhancements for the new UMP 1.1 features. Update the documentation accordingly. Link: https://lore.kernel.org/r/20230612081054.17200-11-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-12ALSA: ump: Add info flag bit for static blocksTakashi Iwai
UMP v1.1 spec allows to inform whether the function blocks are static and not dynamically updated. Add a new flag bit to snd_ump_endpoint_info to reflect that attribute, too. The flag is set when a USB MIDI device is still in the old MIDI 2.0 without UMP 1.1 support. Then the driver falls back to GTBs, and they are supposed to be static-only. Link: https://lore.kernel.org/r/20230612081054.17200-10-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-12ALSA: seq: ump: Notify UMP protocol change to sequencerTakashi Iwai
UMP v1.1 supports the protocol switch via a UMP Stream message. When it's received, we need to take care of the midi_version field in the corresponding sequencer client, too. This patch introduces a new ops to notify the protocol change to snd_seq_ump_ops for handling it. Link: https://lore.kernel.org/r/20230612081054.17200-9-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-12ALSA: seq: ump: Notify port changes to system portTakashi Iwai
For allowing applications to track the FB active changes, this patch adds the notification from the system port at each time a FB change is handled and the active flag or re-grouping happens. Link: https://lore.kernel.org/r/20230612081054.17200-8-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-12ALSA: seq: ump: Handle FB info updateTakashi Iwai
This patch implements the handling of the dynamic update of FB info. When the FB info update is received after the initial parsing, it means the dynamic FB info update. We compare the result, and if the actual update is detected, it's notified via a new ops, notify_fb_change, to the sequencer client, and the corresponding sequencer ports are updated accordingly. Link: https://lore.kernel.org/r/20230612081054.17200-7-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-12ALSA: seq: ump: Handle groupless messagesTakashi Iwai
The UMP Utility and Stream messages are "groupless", i.e. an incoming groupless packet should be sent only to the UMP EP port, and the event with the groupless message is sent to UMP EP as is without the group translation per port. Also, the former reserved bit 0 for the client group filter is now used for groupless events. When the bit 0 is set, the groupless events are filtered out and skipped. Link: https://lore.kernel.org/r/20230612081054.17200-6-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-12ALSA: usb-audio: Add midi2_ump_probe optionTakashi Iwai
Add a new option to enable/disable the UMP Endpoint probing. Some firmware seems screwed up when such a new command issued, and this option allows user to suppress it. Link: https://lore.kernel.org/r/20230612081054.17200-5-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-12ALSA: usb-audio: Parse UMP Endpoint and Function Blocks at firstTakashi Iwai
Try to parse the UMP Endpoint and UMP Function Blocks for building the topology at first. Only when those are missing (e.g. on an older USB MIDI 2.0 spec or a unidirectional endpoint), the driver still creates blocks based on USB group terminal block information as fallback. Link: https://lore.kernel.org/r/20230612081054.17200-4-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-12ALSA: ump: Support UMP Endpoint and Function Block parsingTakashi Iwai
This patch adds the basic support for UMP Endpoint and UMP Function Block parsing, which are extended in the new UMP v1.1 spec. The patch provides a new helper function to perform the query of the UMP Endpoint information and builds up the UMP blocks based on UMP Function Block information. For the communication over the UMP Endpoint, it opens the rawmidi device once internally, inquiries the UMP Endpoint and Function Block info by sending new UMP Stream messages, and waits for the response for each query. The new UMP spec allows to update the FB info and change its associated groups or its activeness on the fly, too. For catching it, the UMP core keeps watching the incoming UMP messages, and snd_ump_receive() handles the incoming UMP Stream messages to refresh the FB info. Link: https://lore.kernel.org/r/20230612081054.17200-3-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-12ALSA: ump: Add more attributes to UMP EP and FB infoTakashi Iwai
Add a few more fields to snd_ump_endpoint_info and snd_ump_block_info that are added in the new v1.1 spec. Those are filled by the UMP Stream messages. The rawmidi protocol version is bumped to 2.0.4 to indicate those updates. Also, update the proc outputs to show the newly introduced fields. Link: https://lore.kernel.org/r/20230612081054.17200-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-12ALSA: firewire: use 'GPL' string for module license contributed by Clemens ↵Takashi Sakamoto
Ladisch In MODULE_LICENSE macro, "GPL" string obsoletes "GPL v2" string by a commit bf7fbeeae6db ("module: Cure the MODULE_LICENSE "GPL" vs. "GPL v2" bogosity"). This commit uses the preferable expression. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20230611144445.221529-3-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-12ALSA: firewire: use 'GPL' string for module license contributed by Takashi ↵Takashi Sakamoto
Sakamoto In MODULE_LICENSE macro, "GPL" string obsoletes "GPL v2" string by a commit bf7fbeeae6db ("module: Cure the MODULE_LICENSE "GPL" vs. "GPL v2" bogosity"). This commit uses the preferable expression. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20230611144445.221529-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-11ALSA: hda: Use maple tree register cacheMark Brown
HDA can only support single register read and write operations so does not benefit from block writes. This means it gets no benefit from using the rbtree register cache over the maple tree register cache so convert it to use maple trees instead, it is more modern. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230609-alsa-hda-maple-v1-1-a2b725c8b8f5@kernel.org Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-10ALSA: hda/realtek: Add a quirk for Compaq N14JP6Edson Juliano Drosdeck
Add a quirk for Compaq N14JP6 to fixup ALC897 headset MIC no sound. Signed-off-by: Edson Juliano Drosdeck <edson.drosdeck@gmail.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20230609201058.523499-1-edson.drosdeck@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-07selftests: ALSA: Add test for the 'pcmtest' driverIvan Orlov
This test covers the new Virtual PCM Test Driver, including the capturing, playback and ioctl redefinition functionalities for both interleaved and non-interleaved access modes. This test is also helpful as an usage example of the 'pcmtest' driver. We have a lot of different virtual media drivers, which can be used for testing of the userspace applications and media subsystem middle layer. However, all of them are aimed at testing the video functionality and simulating the video devices. For audio devices we have only snd-dummy module, which is good in simulating the correct behavior of an ALSA device. I decided to write a tool, which would help to test the userspace ALSA programs (and the PCM middle layer as well) under unusual circumstances to figure out how they would behave. So I came up with this Virtual PCM Test Driver. This new Virtual PCM Test Driver has several features which can be useful during the userspace ALSA applications testing/fuzzing, or testing/fuzzing of the PCM middle layer. Not all of them can be implemented using the existing virtual drivers (like dummy or loopback). Here is what can this driver do: - Simulate both capture and playback processes - Generate random or pattern-based capture data - Check the playback stream for containing the looped pattern - Inject delays into the playback and capturing processes - Inject errors during the PCM callbacks Also, this driver can check the playback stream for containing the predefined pattern, which is used in the corresponding selftest to check the PCM middle layer data transferring functionality. Additionally, this driver redefines the default RESET ioctl, and the selftest covers this PCM API functionality as well. The driver supports both interleaved and non-interleaved access modes, and have separate pattern buffers for each channel. The driver supports up to 4 channels and up to 8 substreams. Signed-off-by: Ivan Orlov <ivan.orlov0322@gmail.com> Acked-by: Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20230606193254.20791-3-ivan.orlov0322@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-07ALSA: Implement the new Virtual PCM Test DriverIvan Orlov
We have a lot of different virtual media drivers, which can be used for testing of the userspace applications and media subsystem middle layer. However, all of them are aimed at testing the video functionality and simulating the video devices. For audio devices we have only snd-dummy module, which is good in simulating the correct behavior of an ALSA device. I decided to write a tool, which would help to test the userspace ALSA programs (and the PCM middle layer as well) under unusual circumstances to figure out how they would behave. So I came up with this Virtual PCM Test Driver. This new Virtual PCM Test Driver has several features which can be useful during the userspace ALSA applications testing/fuzzing, or testing/fuzzing of the PCM middle layer. Not all of them can be implemented using the existing virtual drivers (like dummy or loopback). Here is what can this driver do: - Simulate both capture and playback processes - Generate random or pattern-based capture data - Inject delays into the playback and capturing processes - Inject errors during the PCM callbacks Also, this driver can check the playback stream for containing the predefined pattern, which is used in the corresponding selftest to check the PCM middle layer data transferring functionality. Additionally, this driver redefines the default RESET ioctl, and the selftest covers this PCM API functionality as well. The driver supports both interleaved and non-interleaved access modes, and have separate pattern buffers for each channel. The driver supports up to 4 channels and up to 8 substreams. Signed-off-by: Ivan Orlov <ivan.orlov0322@gmail.com> Acked-by: Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20230606193254.20791-2-ivan.orlov0322@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-07docs: sound: add 'pcmtest' driver documentationIvan Orlov
Add documentation for the new Virtual PCM Test Driver. It covers all possible usage cases: errors and delay injections, random and pattern-based data generation, playback and ioctl redefinition functionalities testing. We have a lot of different virtual media drivers, which can be used for testing of the userspace applications and media subsystem middle layer. However, all of them are aimed at testing the video functionality and simulating the video devices. For audio devices we have only snd-dummy module, which is good in simulating the correct behavior of an ALSA device. I decided to write a tool, which would help to test the userspace ALSA programs (and the PCM middle layer as well) under unusual circumstances to figure out how they would behave. So I came up with this Virtual PCM Test Driver. This new Virtual PCM Test Driver has several features which can be useful during the userspace ALSA applications testing/fuzzing, or testing/fuzzing of the PCM middle layer. Not all of them can be implemented using the existing virtual drivers (like dummy or loopback). Here is what can this driver do: - Simulate both capture and playback processes - Check the playback stream for containing the looped pattern - Generate random or pattern-based capture data - Inject delays into the playback and capturing processes - Inject errors during the PCM callbacks Also, this driver can check the playback stream for containing the predefined pattern, which is used in the corresponding selftest to check the PCM middle layer data transferring functionality. Additionally, this driver redefines the default RESET ioctl, and the selftest covers this PCM API functionality as well. The driver supports both interleaved and non-interleaved access modes, and have separate pattern buffers for each channel. The driver supports up to 4 channels and up to 8 substreams. Signed-off-by: Ivan Orlov <ivan.orlov0322@gmail.com> Acked-by: Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20230606193254.20791-1-ivan.orlov0322@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>