[LAD] Monitor Alsa dummy mixer control in realtime
Hello all,
I want to write an application that monitors in realtime changes in an Alsa
dummy mixer control (though not sure which language yet). I think its best to
try to track those changes through the filesystem. For non-dummy mixer controls
I can access them through: /proc/asound/cardx/codecxxx/+regs. However, it
seems that this does not work for this dummy mixer control. Can someone point
me a bit in a direction where I should for a solution (language/library)?
Whichever language I use I still have quite a bit to learn. However, I do would
like to find out whether it is even possible in a certain language before I
invest a lot of effort in it (without result). I've tried Python, but getting
it working in realtime is likely going to be very hard (if possible at all).
Kind regards, Maarten
ps. I've defined the dummy mixer control in /var/lib/alsa/asound.state
as shown below:
state.DAC {
control.12345 {
iface MIXER
name 'Fake Playback Volume'
value 100
comment {
access 'read write user'
type INTEGER
count 1
range '0 - 100'
}
}
}
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Monitor Alsa dummy mixer control in realtime
On Oct 31, 2012, at 13:30 54, Muffinman wrote: but getting it working in realtime is likely going to be very hard (if possible at all). The realtime requirement rules out anything with automatic memory management --i.e. pretty much any higher-level interpreted language. Effectively, it means you're limited to C or C++. Cheers! |-| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |-| | Only those who leisurely approach that which the masses are busy about | | can be busy about that which the masses take leisurely. | | -- Lao Tsu| |-| ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] concurrent access on smp
On 22/10/12 01:34, Emanuel Rumpf wrote: Hi With some threads running on different CPU, accessing a shared pointer (in RAM) atomically (with gcc atomic methods) my current understanding is: - each cpu has its own cache line - which is updated on every atomic read/write operation 1. is that applicable ? 2. is there a faster or more convenient method, such as storing the pointer in fast register shared among different cpu ? Depends on how you design your data structures and on the specific platform. On x86 reads and writes of pointers are atomic so you won't ever end up with the corrupt pointer, but you may end up with a stale one. This may be, or may not be a problem, depending on your use and design, and there are ways of designing things around it. If applicable to your use case. If your data structures and their use require locking, which you would like to avoid, there is a concept called Read-Copy-Update which is for example heavily used in the kernel and is also available as an userspace library (http://lttng.org/urcu). Tvrtko ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] concurrent access on smp
If your data structures and their use require locking, which you would like to avoid, there is a concept called Read-Copy-Update which is for example heavily used in the kernel and is also available as an userspace library (http://lttng.org/urcu). Yes, the RCU approach is quite effective. However, better to not call it that since IBM has a patent on it last I checked. -- Paul ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
