- 13 Jun, 2023 9 commits
-
-
Oswald Buddenhagen authored
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.deSigned-off-by:
Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
The timer was presuming a fixed 48 kHz word clock, like the rest of the code. Signed-off-by:
-
Oswald Buddenhagen authored
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 authored
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 authored
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 authored
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 authored
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 authored
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:
-
Takashi Iwai authored
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.deSigned-off-by:
-
- 12 Jun, 2023 12 commits
-
-
Takashi Iwai authored
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.deSigned-off-by:
-
Takashi Iwai authored
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.deSigned-off-by:
-
Takashi Iwai authored
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.deSigned-off-by:
-
Takashi Iwai authored
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.deSigned-off-by:
-
Takashi Iwai authored
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.deSigned-off-by:
-
Takashi Iwai authored
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.deSigned-off-by:
-
Takashi Iwai authored
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.deSigned-off-by:
-
Takashi Iwai authored
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.deSigned-off-by:
-
Takashi Iwai authored
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.deSigned-off-by:
-
Takashi Iwai authored
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.deSigned-off-by:
-
Takashi Sakamoto authored
In MODULE_LICENSE macro, "GPL" string obsoletes "GPL v2" string by a commit bf7fbeea ("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.jpSigned-off-by:
-
Takashi Sakamoto authored
In MODULE_LICENSE macro, "GPL" string obsoletes "GPL v2" string by a commit bf7fbeea ("module: Cure the MODULE_LICENSE "GPL" vs. "GPL v2" bogosity"). This commit uses the preferable expression. Signed-off-by:
-
- 11 Jun, 2023 1 commit
-
-
Mark Brown authored
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.orgSigned-off-by:
-
- 07 Jun, 2023 7 commits
-
-
Ivan Orlov authored
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.comSigned-off-by:
-
Ivan Orlov authored
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 authored
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:
-
Yanteng Si authored
On loongson controller, the value of WALLCLK register is always 0, which is meaningless, so we return directly. Signed-off-by:
Yanteng Si <siyanteng@loongson.cn> Signed-off-by:
Yingkun Meng <mengyingkun@loongson.cn> Acked-by:
Huacai Chen <chenhuacai@loongson.cn> Link: https://lore.kernel.org/r/185df71ef413ab190460eb377703214ee7288aeb.1686128807.git.siyanteng@loongson.cnSigned-off-by:
-
Yanteng Si authored
On loongson controller, after calling snd_hdac_stream_updateb() to enable DMA engine, the SDnCTL.STRM will become to zero. We need to access SDnCTL in dword to keep SDnCTL.STRM is not changed. Signed-off-by:
-
Yanteng Si authored
On loongson controller, RIRBSTS.RINTFL cannot be cleared, azx_interrupt() is called all the time. We disable RIRB interrupt, and use polling mode by default. Signed-off-by:
-
Yanteng Si authored
Add the new PCI ID 0x0014 0x7a07 and the new PCI ID 0x0014 0x7a37 Loongson HDA controller. Signed-off-by:
-
- 06 Jun, 2023 4 commits
-
-
Takashi Iwai authored
We don't need to change the numid at each time snd_ctl_rename_id() is called, as the control element size itself doesn't change. Let's keep the previous numid value. Along with it, add a note about calling this function only in the card init phase. Reviewed-by:
-
Stefan Binding authored
This ensures that the driver is properly cleaned up when freed. Signed-off-by:
Stefan Binding <sbinding@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230606103436.455348-4-sbinding@opensource.cirrus.comSigned-off-by:
-
Stefan Binding authored
Found during static analysis, ensure variables are correct types before endian conversion. Signed-off-by:
-
Stefan Binding authored
Ensure Firmware Load control and Firmware Type control returns 1 when the value changes. Remove fw_mutex from firmware load control put, since it is unnecessary, and prevents any possibility of mutex inversion. Signed-off-by:
-
- 05 Jun, 2023 7 commits
-
-
Takashi Iwai authored
Pull fixes for a couple of minor issues spotted by bots. Signed-off-by: -
Takashi Iwai authored
Currently the read event packet size in snd_seq_read() is defined by client->midi_version value that is guaranteed to be zero if UMP isn't enabled. But the static analyzer doesn't know of the fact, and it still suspects as if it were leading to a potential overflow. Add the more explicit check of CONFIG_SND_SEQ_UMP to determine the aligned_size value for avoiding the confusion. Fixes: 46397622 ("ALSA: seq: Add UMP support") Reported-by:
kernel test robot <lkp@intel.com> Reported-by:
Dan Carpenter <error27@gmail.com> Closes: https://lore.kernel.org/r/202305261415.NY0vapZK-lkp@intel.com/ Link: https://lore.kernel.org/r/20230605144758.6677-2-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
Use proper notion for 16bit values for fixing the sparse warnings. Fixes: f8ddb0fb ("ALSA: usb-audio: Define USB MIDI 2.0 specs") Reported-by:
-
Oswald Buddenhagen authored
- Include the FX bus map, without which the already present send routing info would require looking up the documentation. - Include the physical I/O channels as known to the driver - Make the multi-channel capture map actually name the mapped input channels rather than "FXBUS" (Audigy) or even "???" (SbLive) - The latter two are omitted for E-MU cards, as their physical I/O is routed through the FPGA - While at it, make the "Card" field somewhat more useful This includes de-duplicating the label tables between emuproc and emufx, updating/improving the FX bus label table, and making the SB Live! 5.1 multi-track capture channel mapping hack data-driven. Tested-by:
Jonathan Dowland <jon@dow.land> Signed-off-by:
-
Oswald Buddenhagen authored
Include the routing information, which can be actually read back. Somewhat as a drive-by, make the register dump format less obscure - the previous one made no sense at all. Signed-off-by:
-
Oswald Buddenhagen authored
It seems to make little sense to include the FX send routing, but not the amounts. This also simplifies the code somewhat, and lines up the output. Signed-off-by:
-
Oswald Buddenhagen authored
fx8010_acode is supposed to be a human-readable representation; the binary is already in fx8010_code. Signed-off-by:
-
