- 09 Jun, 2021 2 commits
-
-
Takashi Iwai authored
The handling of snd_ctl_new1() and snd_ctl_add() can be sometimes tricky, as snd_ctl_add() automatically removes the passed object at its error path. The recent fix addressed an overlooked issue that is relevant with that in SB driver code, and it can be a bit more simplified by assigning to a temporary variable, i.e. storing to the struct field only after the creation succeeds. Link: https://lore.kernel.org/r/20210608140540.17885-3-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
A lot of code for SB drivers is in a legacy style with assignment in if condition. This also made harder to catch some bugs (e.g. the commit 1c98f574 "ALSA: emu8000: Fix a use after free in snd_emu8000_create_mixer"). This patch fixes the coding style. All are rather simple conversions and there should be no functional changes. (The changes in snd_emu8000_new() for hw->res_port1, 2 and 3 are slightly different from the older ones, but this shouldn't matter much in practice.) Link: https://lore.kernel.org/r/20210608140540.17885-2-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
- 08 Jun, 2021 5 commits
-
-
Geoffrey D. Bennett authored
Add support for retrieving the mux configuration from the hardware when the driver is initialising. Previously the ALSA controls were initialised to a default hard-coded state instead of being initialised to match the hardware state. Fixes: 9e4d5c1b ("ALSA: usb-audio: Scarlett Gen 2 mixer interface") Suggested-by: Vladimir Sadovnikov <sadko4u@gmail.com> Tested-by: Markus Schroetter <project.m.schroetter@gmail.com> Tested-by: Alex Fellows <alex.fellows@gmail.com> Tested-by: Daniel Sales <daniel.sales.z@gmail.com> Signed-off-by: Geoffrey D. Bennett <g@b4.vu> Link: https://lore.kernel.org/r/15b17c60a2bca174bcddcec41c9419b746f21c1d.1623091570.git.g@b4.vuSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Geoffrey D. Bennett authored
Add support for reading the mixer volumes from the hardware when the driver is initialising. Previously these ALSA volume controls were initialised to zero instead of being initialised to match the hardware state. Fixes: 9e4d5c1b ("ALSA: usb-audio: Scarlett Gen 2 mixer interface") Suggested-by: Vladimir Sadovnikov <sadko4u@gmail.com> Tested-by: Markus Schroetter <project.m.schroetter@gmail.com> Tested-by: Alex Fellows <alex.fellows@gmail.com> Tested-by: Daniel Sales <daniel.sales.z@gmail.com> Signed-off-by: Geoffrey D. Bennett <g@b4.vu> Link: https://lore.kernel.org/r/bb33fa9b79efc6f7a0f0e6fb7018cc8d4d59b3ba.1623091570.git.g@b4.vuSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
-
Jeremy Szu authored
The HP ZBook Power G8 using ALC236 codec which using 0x02 to control mute LED and 0x01 to control micmute LED. Therefore, add a quirk to make it works. Signed-off-by: Jeremy Szu <jeremy.szu@canonical.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210608114750.32009-1-jeremy.szu@canonical.comSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Hui Wang authored
There are 2 issues on this machine, the 1st one is mic's plug/unplug can't be detected, that is because the mic is set to manual detecting mode, need to apply ALC255_FIXUP_XIAOMI_HEADSET_MIC to set it to auto detecting mode. The other one is headphone's plug/unplug can't be detected by pulseaudio, that is because the pulseaudio will use ucm2/sof-hda-dsp on this machine, and the ucm2 only handle 'Headphone Jack', but on this machine the headphone's pincfg sets the location to Front, then the alsa mixer name is "Front Headphone Jack" instead of "Headphone Jack", so override the pincfg to change location to Left. BugLink: http://bugs.launchpad.net/bugs/1930188 Cc: <stable@vger.kernel.org> Signed-off-by: Hui Wang <hui.wang@canonical.com> Link: https://lore.kernel.org/r/20210608024600.6198-1-hui.wang@canonical.comSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
- 07 Jun, 2021 9 commits
-
-
Takashi Sakamoto authored
No driver use snd_fw_schedule_registration(). Let's delete it. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20210607081250.13397-10-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Sakamoto authored
The delayed registration of sound card instance brings less benefit than complication of kobject management. This commit ceases from it. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20210607081250.13397-9-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Sakamoto authored
The delayed registration of sound card instance brings less benefit than complication of kobject management. This commit ceases from it. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20210607081250.13397-8-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Sakamoto authored
The delayed registration of sound card instance brings less benefit than complication of kobject management. This commit ceases from it. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20210607081250.13397-7-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Sakamoto authored
The delayed registration of sound card instance brings less benefit than complication of kobject management. This commit ceases from it. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20210607081250.13397-6-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Sakamoto authored
The delayed registration of sound card instance brings less benefit than complication of kobject management. This commit ceases from it. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20210607081250.13397-5-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Sakamoto authored
The delayed registration of sound card instance brings less benefit than complication of kobject management. This commit ceases from it. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20210607081250.13397-4-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Sakamoto authored
The delayed registration of sound card instance brings less benefit than complication of kobject management. This commit ceases from it. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20210607081250.13397-3-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Sakamoto authored
The delayed registration of sound card instance brings less benefit than complication of kobject management. This commit ceases from it. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20210607081250.13397-2-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
- 06 Jun, 2021 3 commits
-
-
Takashi Sakamoto authored
This commit adds support for the hybrid model of MOTU Ultralite mk3 with alpha connector, which is already discontinued. The hardware specification of the model is the same as the one of FireWire-only model. $ cd linux-firewire-utils $ python3 src/crpp < /sys/bus/firewire/devices/fw1/config_rom ROM header and bus information block ----------------------------------------------------------------- 400 04101573 bus_info_length 4, crc_length 16, crc 5491 404 31333934 bus_name "1394" 408 20ff7000 irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 255, max_rec 7 (256) 40c 0001f200 company_id 0001f2 | 410 000a059c device_id 00000a059c | EUI-64 0001f200000a059c root directory ----------------------------------------------------------------- 414 0004ef04 directory_length 4, crc 61188 418 030001f2 vendor 41c 0c0083c0 node capabilities per IEEE 1394 420 d1000002 --> unit directory at 428 424 8d000005 --> eui-64 leaf at 438 unit directory at 428 ----------------------------------------------------------------- 428 0003f00b directory_length 3, crc 61451 42c 120001f2 specifier id 430 13000030 version 434 17103800 model eui-64 leaf at 438 ----------------------------------------------------------------- 438 0002d89c leaf_length 2, crc 55452 43c 0001f200 company_id 0001f2 | 440 000a059c device_id 00000a059c | EUI-64 0001f200000a059c Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20210606043409.40019-1-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Sakamoto authored
In all of drivers of ALSA firewire stack, the callback of .pointer and .ack in snd_pcm_ops structure is done in acquired spin_lock of PCM substream, therefore already under disabled kernel preemption. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20210606025651.29970-1-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Dan Carpenter authored
Return -ENOMEM if kcalloc() fails. Currently the code returns success. Fixes: f9e5ecdf ("ALSA: firewire-lib: add replay target to cache sequence of packet") Fixes: 6f24bb8a ("ALSA: firewire-lib: pool sequence of packet in IT context independently") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/YLtyL4VoArwVLor1@mwandaSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
- 05 Jun, 2021 5 commits
-
-
Takashi Sakamoto authored
In the workqueue to queue wake-up event, isochronous context is not processed, thus it's useless to check context for the workqueue to switch status of runtime for PCM substream to XRUN. On the other hand, in software IRQ context of 1394 OHCI, it's needed. This commit fixes the bug introduced when tasklet was replaced with workqueue. Cc: <stable@vger.kernel.org> Fixes: 2b3d2987 ("ALSA: firewire: Replace tasklet with work") Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20210605091054.68866-1-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Jeremy Szu authored
The HP EliteBook 840 Aero G8 using ALC285 codec which using 0x04 to control mute LED and 0x01 to control micmute LED. In the other hand, there is no output from right channel of speaker. Therefore, add a quirk to make it works. Signed-off-by: Jeremy Szu <jeremy.szu@canonical.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210605082539.41797-3-jeremy.szu@canonical.comSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Jeremy Szu authored
The HP EliteBook x360 1040 G8 using ALC285 codec which using 0x04 to control mute LED and 0x01 to control micmute LED. In the other hand, there is no output from right channel of speaker. Therefore, add a quirk to make it works. Signed-off-by: Jeremy Szu <jeremy.szu@canonical.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210605082539.41797-2-jeremy.szu@canonical.comSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Jeremy Szu authored
The HP Elite Dragonfly G2 using ALC285 codec which using 0x04 to control mute LED and 0x01 to control micmute LED. In the other hand, there is no output from right channel of speaker. Therefore, add a quirk to make it works. Signed-off-by: Jeremy Szu <jeremy.szu@canonical.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210605082539.41797-1-jeremy.szu@canonical.comSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Werner Sembach authored
Change the name string of several devices needing quirks to the Clevo-barebone ones. Also make the names follow the same pattern for multiple Clevo names referring to the same mainboard. Signed-off-by: Werner Sembach <wse@tuxedocomputers.com> Link: https://lore.kernel.org/r/20210604140207.8023-1-wse@tuxedocomputers.comSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
- 04 Jun, 2021 1 commit
-
-
Yang Yingliang authored
Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: e50dfac8 ("ALSA: firewire-motu: cache event ticks in source packet header per data block") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20210603143203.582017-1-yangyingliang@huawei.comSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
- 03 Jun, 2021 2 commits
-
-
Hui Wang authored
The patch_realtek.c needs to check if the power_state.event equals PM_EVENT_SUSPEND, after using the direct-complete, the suspend() and resume() will be skipped if the codec is already rt_suspended, in this case, the patch_realtek.c will always get PM_EVENT_ON even the system is really resumed from S3. We could set power_state to PMSG_SUSPEND in the prepare(), if other PM functions are called before complete(), those functions will override power_state; if no other PM functions are called before complete(), we could know the suspend() and resume() are skipped since only S3 pm functions could be skipped by direct-complete, in this case set power_state to PMSG_RESUME in the complete(). This could guarantee the first time of calling hda_codec_runtime_resume() after complete() has the correct power_state. Fixes: 215a22ed ("ALSA: hda: Refactor codec PM to use direct-complete optimization") Cc: <stable@vger.kernel.org> Signed-off-by: Hui Wang <hui.wang@canonical.com> Link: https://lore.kernel.org/r/20210602145424.3132-1-hui.wang@canonical.comSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
snd_timer_notify1() calls the notification to each slave for a master event, but it passes a wrong event number. It should be +10 offset, corresponding to SNDRV_TIMER_EVENT_MXXX, but it's incorrectly with +100 offset. Casually this was spotted by UBSAN check via syzkaller. Reported-by: syzbot+d102fa5b35335a7e544e@syzkaller.appspotmail.com Reviewed-by: Jaroslav Kysela <perex@perex.cz> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/000000000000e5560e05c3bd1d63@google.com Link: https://lore.kernel.org/r/20210602113823.23777-1-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
- 02 Jun, 2021 9 commits
-
-
Dongliang Mu authored
The snd_ctl_led_sysfs_add and snd_ctl_led_sysfs_remove should contain the refcount operations in pair. However, snd_ctl_led_sysfs_remove fails to decrease the refcount to zero, which causes device_release never to be invoked. This leads to memory leak to some resources, like struct device_private. In addition, we also free some other similar memory leaks in snd_ctl_led_init/snd_ctl_led_exit. Fix this by replacing device_del to device_unregister in snd_ctl_led_sysfs_remove/snd_ctl_led_init/snd_ctl_led_exit. Note that, when CONFIG_DEBUG_KOBJECT_RELEASE is enabled, put_device will call kobject_release and delay the release of kobject, which will cause use-after-free when the memory backing the kobject is freed at once. Reported-by: syzbot+08a7d8b51ea048a74ffb@syzkaller.appspotmail.com Fixes: a135dfb5 ("ALSA: led control - add sysfs kcontrol LED marking layer") Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com> Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20210602034136.2762497-1-mudongliangabcd@gmail.comSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
USB-audio driver behaves a bit strangely for the playback stream -- namely, it starts sending silent packets at PCM prepare state while the actual data is submitted at first when the trigger START is kicked off. This is a workaround for the behavior where URBs are processed too quickly at the beginning. That is, if we start submitting URBs at trigger START, the first few URBs will be immediately completed, and this would result in the immediate period-elapsed calls right after the start, which may confuse applications. OTOH, submitting the data after silent URBs would, of course, result in a certain delay of the actual data processing, and this is rather more serious problem on modern systems, in practice. This patch tries to revert the workaround and lets the URB submission starting at PCM trigger for the playback again. As far as I've tested with various backends (native ALSA, PA, JACK, PW), I haven't seen any problems (famous last words :) Note that the capture stream handling needs no such workaround, since the capture is driven per received URB. Link: https://lore.kernel.org/r/20210601162457.4877-6-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
Just minor code refactoring. Like DOP DSD code, it can be better in a separate function for code readability. Link: https://lore.kernel.org/r/20210601162457.4877-5-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The PCM delay accounting in USB-audio driver is a bit complex to follow, and this is an attempt to improve the readability and provide some potential fix. Basically, the PCM position delay is calculated from two factors: the in-flight data on URBs and the USB frame counter. For the playback stream, we advance the hwptr already at submitting URBs. Those "in-flight" data amount is now tracked, and this is used as the base value for the PCM delay correction. The in-flight data is decreased again at URB completion in return. For the capture stream, OTOH, there is no in-flight data, hence the delay base is zero. The USB frame counter is used in addition for correcting the current position. The reference frame counter is updated at each submission and receiving time, and the difference from the current counter value is taken into account. In this patch, each in-flight data bytes is recorded in the new snd_usb_ctx.queued field, and the total in-flight amount is tracked in snd_usb_substream.inflight_bytes field, as the replacement of last_delay field. Note that updating the hwptr after URB completion doesn't work for PulseAudio who tries to scratch the buffer on the fly; USB-audio is basically a double-buffer implementation, hence the scratching the buffer can't work for the already submitted data. So we always update hwptr beforehand. It's not ideal, but the delay account should give enough correctness. Link: https://lore.kernel.org/r/20210601162457.4877-4-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
There are a bunch of lines calculating the buffer size in bytes at each time. Keep the value in subs->buffer_bytes and use it consistently for the code simplicity. Link: https://lore.kernel.org/r/20210601162457.4877-3-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
It's a local function, let's make it static. Link: https://lore.kernel.org/r/20210601162457.4877-2-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Sakamoto authored
This commit takes ALSA firewire-motu driver to perform sequence replay for media clock recovery. Unlike the other types of device, the devices in MOTU FireWire series require two levels of sequence replay; the sequence of the number of data blocks per packet and the sequence of source packet header per data block. The former is already cached by ALSA IEC 61883-1/6 packet streaming engine and ready to be replayed. The latter is also cached by ALSA firewire-motu driver itself with a previous patch. This commit takes the driver to replay both of them from the caches. The sequence replay is tested with below models: * 828 mkII * Traveler * UltraLite * 828 mk3 FireWire * 828 mk3 Hybrid (except for high sampling transfer frequency * UltraLite mk3 FireWire * 4pre * AudioExpress Unfortunately, below models still don't generate better sound, requires more work: * 8pre * 828 mk3 Hybrid at high sampling transfer frequency As long as I know, MOTU protocol version 1 requires extra care of the format of data block, thus below models are not supported yet in this time: * 828 * 896 Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20210602013406.26442-4-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Sakamoto authored
The devices in MOTU FireWire series put source packet header (SPH) into each data block of tx packet for presentation time of event. The format of timestamp is compliant to IEC 61883-1, with cycle and offset fields without sec field of 32 bit cycle time. This commit takes ALSA firewire-motu driver to cache the presentation time as offset from cycle in which the packet is transferred. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20210602013406.26442-3-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Sakamoto authored
ALSA firewire-motu driver has some magic numbers from IEC 61883-1 to operates source packet header (SPH). This commit replaces them with macros. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20210602013406.26442-2-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
- 01 Jun, 2021 4 commits
-
-
Takashi Sakamoto authored
This commit takes ALSA bebob driver to perform sequence replay for media clock recovery. Many users have reported discontinuity of data block counter field of CIP header in tx packet from the devices based on BeBoB ASICs. In the worst case, the device corrupts not to respond to any transaction, then generate bus-reset voluntarily for recovery. The sequence replay for media clock recovery is expected to suppress most of the problems. In the beginning of packet streaming, the device transfers NODATA packets for a while, then multiplexes any event and syt information. ALSA IEC 61883-1/6 packet streaming engine has implementation for it to drop the initial NODATA packets. It starts sequence replay when detecting any event multiplexed to tx packets. The sequence replay is tested with below models: * Focusrite Saffire * Focusrite Saffire LE * Focusrite Saffire Pro 10 I/O * Focusrite Saffire Pro 26 I/O * M-Audio FireWire Solo * M-Audio FireWire Audiophile * M-Audio Ozonic * M-Audio FireWire 410 * M-Audio FireWire 1814 * Edirol FA-66 * ESI Quatafire 610 * Apogee Ensemble * Phonic Firefly 202 * Behringer F-Control Audio 610 Unfortunately, below models doesn't generate sound. This seems regression introduced recent few years: * Stanton Final Scratch ScratchAmp at middle sampling transfer frequency * Yamaha GO44 * Yamaha GO46 * Terratec Phase x24 As I reported, below model has quirk of discontinuity: * M-Audio ProFire Lightbridge DM1000/DM1100 ASICs in BeBoB solution are known to have bugs at switch of sampling transfer frequency between low/middle/high rates. The switch generates the similar problems about which I mention in the above. Some vendors customizes firmware so that the switch of frequency is done in vendor-specific registers, then restrict users to switch the frequency. For example of Focusrite Saffire Pro 10 i/o and 26 i/o, users allows to switch the frequency within the three steps; e.g. 44.1/48.0 kHz are available at low step. Between the steps, extra operation is required and it always generates bus-reset. Another example of Edirol FA-66, users are prohibited to switch the frequency by software. It's done by hardware switch and power-off. I note that the sequence replay is not a solution for the ASIC bugs. Users need to disconnect the device corrupted by the bug, then reconnect it to refresh state machine inner the ASIC. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20210601081753.9191-4-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Sakamoto authored
This commit takes ALSA dice driver to perform sequence replay for media clock recovery. Unlike the other types of device, DICE-based devices interpret the value of syt field of CIP header in rx packets as presentation time for audio playback, thus it's required for driver to compute value for outgoing packet adequate to the device. It's done by media clock recovery by handling tx packets. The device starts packet transmission immediately at operation to GLOBAL_ENABLE thus on-the-fly mode is not required. DICE ASICs supports several pairs of isochronous packet streams. Actually, maximum two pairs of streams are supported by devices. We have three cases regarding to the number of streams: 1. a pair of streams 2. two tx packet streams and one rx packet streams 3. one tx packet streams and two rx packet streams 4. two pair of streams The decision of playback timing is slightly different in the four cases. In the case 1, sequence replay in the pair results in suitable playback timing. In the case 2, sequence replay from the first tx packet stream to rx packet stream results in suitable playback timing. In the case 3, sequence replay from tx packet stream to all of rx packet stream results in suitable playback timing. Furthermore, the cycle to start receiving packets should be the same between all rx packet streams. In the case 4, sequence replay in each pair results in suitable playback timing. Furthermore, the cycle to start receiving packets should be the same between all rx packet streams. The sequence replay is tested with below models: * For case 1: * TC Electronic Konnekt 24d (DiceII) * TC Electronic Konnekt 8 (DiceII) * TC Electronic Konnekt Live (DiceII) * TC Electronic Impact Twin (DiceII) * TC Electronic Digital Konnekt X32 (DiceII) * TC Electronic Desktop Konnekt 6 (TCD2220) * Solid State Logic Duende Classic (DiceII) * Solid State Logic Duende Mini (DiceII) * PreSonus FireStudio Project (TCD2210) * PreSonus FireStudio Mobile (TCD2210) * Lexicon I-ONIX FW810s (TCD2220) * Avid Mbox 3 Pro (TCD2220) * For case 2 (but case 1 depends on sampling transfer frequency): * Alesis iO 26 (DiceII) * Alesis iO 14 (DiceII) * Alesis MultiMix 12 FireWire (DiceII) * Focusrite Saffire Pro 26 (TCD2220) * For case 3 (but case 1 depends on sampling transfer frequency): * M-Audio Profire 610 (TCD2220) * Loud Technology Mackie Onyx Blackbird (TCD2210) * For case 4: * TC Electronic Studio Konnekt 48 (DiceII + TCD2220) * PreSonus FireStudio (DiceII) * M-Audio Profire 2626 (TCD2220) * Focusrite Liquid Saffire 56 (TCD2220) * Focusrite Saffire Pro 40 (TCD2220) Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20210601081753.9191-3-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Sakamoto authored
NOTIFY_CLOCK_ACCEPTED notification is always generated as a result of GLOBAL_CLOCK_SELECT operation, however NOTIFY_LOCK_CHG notification doesn't, as long as the selected clock is already configured. In the case, ALSA dice driver waits so long. It's inconvenient for some devices to lock to the sequence of value in syt field of CIP header in rx packets. This commit wait just for NOTIFY_CLOCK_ACCEPTED notification by reverting changes partially done by two commits below: * commit fbeac84d ("ALSA: dice: old firmware optimization for Dice notification") * commit aec045b8 ("ALSA: dice: change notification mask to detect lock status change") I note that the successful lock to the sequence of value in syt field of CIP header in rx packets results in NOTIFY_EXT_STATUS notification, then EXT_STATUS_ARX1_LOCKED bit stands in GLOBAL_EXTENDED_STATUS register. The notification can occur enough after receiving the batch of rx packets. When the sequence doesn't include value in syt field of CIP header in rx packets adequate to the device, the notification occurs again and the bit is off. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20210601081753.9191-2-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Carlos M authored
For the HP Pavilion 15-CK0xx, with audio subsystem ID 0x103c:0x841c, adding a line in patch_realtek.c to apply the ALC269_FIXUP_HP_MUTE_LED_MIC3 fix activates the mute key LED. Signed-off-by: Carlos M <carlos.marr.pz@gmail.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210531202026.35427-1-carlos.marr.pz@gmail.comSigned-off-by: Takashi Iwai <tiwai@suse.de>
-