вт, 15 окт. 2024 г., 17:06 Andrew Randrianasulu <randrianas...@gmail.com>:
> > > пн, 14 окт. 2024 г., 17:26 Andrew Randrianasulu <randrianas...@gmail.com>: > >> >> >> On Mon, Oct 14, 2024 at 12:21 PM Thomas Huth <th...@redhat.com> wrote: >> >>> On 14/10/2024 11.06, Peter Maydell wrote: >>> > On Mon, 14 Oct 2024 at 02:13, Andrew Randrianasulu >>> > <randrianas...@gmail.com> wrote: >>> >> >>> >> some 8 years ago this patch was sent to qemu-devel: >>> >> >>> >> https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg05333.html >>> >> "[Qemu-devel] [PATCH 7/7] Add ALSA ioctls" >>> >> >>> >> I wonder why it was rejected, may be as part of series? >>> > >>> > Hard to say from this distance, but looking at the patch >>> > I think it probably was just that it was on the end of >>> > a series that did a bunch of other things and the earlier >>> > patches in the series had issues. >>> >>> Yes, looks like there were review comments on the series that were not >>> addressed: >>> >>> https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg05557.html >>> https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg05364.html >>> >>> But mainly one of the problems were that the patches haven't been send >>> in a >>> proper threaded way, so it was hard to follow the series: >>> >>> https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg05546.html >>> >>> Anyway, looking at the other patches, it seems most of them were not >>> related >>> to ALSA, so you might be fine in just picking that patch, get it to work >>> with the latest version of QEMU again and send just that single updated >>> patch to this mailing list again. YMMV of course. >>> >> >> I tried to apply patch but unfortunately mplayer still complain: >> >> [AO_ALSA] alsa-lib: pcm_hw.c:1578:(snd1_pcm_hw_open_fd) USER_PVERSION >> failed >> >> [AO_ALSA] alsa-lib: pcm_dmix.c:1092:(snd_pcm_dmix_open) unable to open >> slave >> [AO_ALSA] Playback open error: Inappropriate ioctl for device >> >> this is 32-bit mplayer/qemu-i386 on top of 64-bit kernel (x86_64) >> >> qemu git 3860a2a8de56fad71db42f4ad120eb7eff03b51f >> >> ./configure --prefix=/usr --target-list=i386-linux-user >> >> > so, may be qemu internal changed a bit, I tried to add MK_PTR around > int/long types in ioctl.h like it was done for alsa timer ctl before > > but what to do with unsingned long in syscall_defs.h ? > > there is abi_int so I changed simple int to that. > > Anyway with attached patch it still fails to play, while arecord -L /aplay > -L show their lists > > normal speaker-test run: > > strace -e ioctl /usr/bin/speaker-test 2>&1 | grep PVERSION > ioctl(3, SNDRV_CTL_IOCTL_PVERSION, 0xff8bd008) = 0 > > ioctl(4, AGPIOC_INFO or SNDRV_PCM_IOCTL_PVERSION, 0xff8bcefc) = 0 > > ioctl(4, AGPIOC_RESERVE or SNDRV_PCM_IOCTL_USER_PVERSION, 0xff8bcf08) = 0 > > failed run with qemu-i386: > > strace -e ioctl qemu-i386 /usr/bin/speaker-test 2>&1 | grep PVERSION > ioctl(3, SNDRV_CTL_IOCTL_PVERSION, 0xff8410ac) = 0 > > ioctl(4, AGPIOC_INFO or SNDRV_PCM_IOCTL_PVERSION, 0xff8410ac) = 0 > Now, this is strange. With additional patch aplay/arecord -l show truncated list of hardware devices. If I set IOCTL(SNDRV_CTL_IOCTL_PCM_NEXT_DEVICE, IOC_R, TYPE_INT) instead ot MK_PTR(TYPE_INT) in linux-user/iocts.h with my two patches then arecord/aplay under qemu-i386 enumerates all host devices again ... > > >> >> >>> >>> Thomas >>> >>>
