Quote:
Originally Posted by elRicharD
OK, I got myself a nice strace, which I attach.
What I can see with a somehow limited Linux devel knowledge is that there are some missing alsa config files at the beginning, and then it looks for some device files that are not present. Then there is this:
Code:
open("/dev/snd/pcmC0D0p", O_RDWR|O_NONBLOCK|0x80000) = 4
fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
close(3) = 0
ioctl(4, AGPIOC_ACQUIRE or APM_IOC_STANDBY, 0xbefbe484) = 0
fcntl64(4, F_GETFL) = 0x80802 (flags O_RDWR|O_NONBLOCK|0x80000)
ioctl(4, AGPIOC_INFO, 0xbefbe5a8) = 0
clock_gettime(CLOCK_MONOTONIC, {4268, 147286896}) = 0
ioctl(4, AGPIOC_SETUP, 0xbefbe478) = 0
mmap2(NULL, 4096, PROT_READ, MAP_SHARED, 4, 0x80000) = -1 ENXIO (No such device or address)
ioctl(4, 0xc0844123, 0xbefbe3b8) = 0
fcntl64(4, F_GETFL) = 0x80802 (flags O_RDWR|O_NONBLOCK|0x80000)
fcntl64(4, F_SETFL, O_RDWR|0x80000 /* O_??? */) = 0
ioctl(4, 0xc0844123, 0xdfb20) = 0
close(4)
That looks suspicious, but I can't make much of it.
If you can look at it, I will appreciate any help. Thanks! |
I read it from the start and my eyes stop at the same point yours did.
It searched for control files for channels 0...31 and found only a control file for channel 0 ...
Then (attempted) to open("/dev/snd/pcmC0D0p" ...
(Under Linux, you can "open" a non-existent file.)
Grabbed the GPIO pin it needed
Grabbed the constant clock it needed
Tried to memory map the output device - which failed because it did not exist.
No place to write the output bits and bytes - you will not hear anything.
Next highly technical question: Why?
Recent Linux kernels do "dynamic device creation" -
Your kernel may not be new enough (or may not be optioned at build time) to do that.
Translation:
Get a version of this application that does not expect "dynamic device creation".
How?
You might be able to configure the application at build time not to expect "dynamic device creation" - check the build configuration options of the application.
If that feature is not made visible in the configuration options - check which version of the kernel headers you are building against.
You want to be certain you are not using
NEWER kernel headers than the kernel version you are running. (OLDER is ok if the app builds)
I.E: The expectation of dynamic device creation may be controlled by the kernel header files.
Check the /dev/snd/* file system sub-tree -
What devices do you have?
Do you have a device but not a control configuation file?
I.E: Maybe you only have "/dev/snd/pcmC31D0p" and only a config file for "/dev/snd/pcmC0D0p".
Make config files for the device(s) that you actually have.
And/Or: manually make a device node for "/dev/snd/pcmC0D0p" which the software (and the config file) expects.
Duh...
Probably some other things, but those popped to mind first.
Tell us what you try and the results of your trials.
Duh 2:
Play some music with the Kindle's built-in player;
While the music is playing, SSH into the Kindle and inspect the /dev/snd/* sub-tree of the file system;
Discover what device names are present
while the music plays.
Or, if your Kindle model doesn't have a music player, enable TTS and do the above while it is talking to you.
We KNOW the KT can make sounds - We just need to find the device name it is using (which may be dynamic) and then work forward with that knowledge.
Hint:
uname -a
Will tell us the details of the kernel version you are running.
Post that output when you get a chance.
Duh 3:
Why did it continue with the sign-on message after it knew the device did not exist?
That is a built-in delay for the dynamic device creation system to do its thing.
The message string output is slow and blocking (allowing multiple task schedulings) while being output.
After a serious of failures, the application re-tried to setup the output device (presuming it had how waited long enough for the dynamic device setup to have been completed by the kernel).
So it seems clear that this application is expecting dynamic device creation and even allows for very slow dynamic device creation. (maybe not slow enough?)