Hi, I'm debugging a tedious problem with xoscope package in the last Ubuntu 11.10. Xoscope needs padsp to work but when I launch it I obtain this error: utils/padsp.c: dsp_open() utils/padsp.c: fd_info_new() utils/padsp.c: dsp_open() succeeded, fd=8 utils/padsp.c: unknown ioctl 0xffffffffc0045006 utils/padsp.c: freeing fd info (fd=8) utils/padsp.c: Draining. I digged the xoscope's source code and finally I found that the error is raised calling: ioctl(d, request, argp) whit d -> /dev/dsp, request -> SNDCTL_DSP_CHANNELS (line 172 of sc_linux.c). I cannot find anything wrong with this code. I think the problem could be calling the wrong ioctl on the wrong device (mixer instead of dsp) but I cannot find confirmation myself, because my limeted knowledge of pulseaudio and xoscope source code. Is this a pulseaudio bug? I'm intrested in collaborating, so if the bug is a sort of "junior job" I'm glad if I can solve myself with your help. Thank you.
If you are correct that the failing ioctl is SNDCTL_DSP_CHANNELS, then it seems that you are also correct in suggesting that xoscope issues the ioctl on the wrong device (mixer instead of dsp). So, I guess the best way forward would be to try to fix the xoscope code.
Thank you for the quick reply. I cannot really understand how I can fix the problem in xoscope. I'm explaining better. The code that initializes and issues ioctl is no more than 50 lines. I think that it's really simple (follows a pseudocode): Opening the device snd = open("/dev/dsp", O_RDONLY | O_NDELAY)) then: ioctl(snd, SNDCTL_DSP_CHANNELS, 2) This ioctl fails whit the error I reported. If I comment this ioctl, xoscope works, so I'm sure that this is the source of error. In this code is stated crearly that the device is /dev/dsp, not mixer or anything else. I'm not the original author of xoscope, I'm trying to fix an Ubuntu problem that appeared after the Ubuntu 10.04 LTS (on the ubuntu 10.04 lts xoscope works great). Thank you for your support.
OK, i solved, it was a bug in xoscope. The variable preposed to store the IOCTL was a signed integer, that when passed to the unsigned long of padsp ioctl function, produced a wrong ioctl in the form of 0xffffffffc0045006, when it was expected to be 0xc0045006. Change the signed to unsigned int solves the problem. Thank you for your support!
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.