| MNZ | so the default device is a softvol that dumps into dmix, and PA connects directly to dmix, if PA connects then the softvol is muted. PA will just sit idle most of the time except for calls | 00:00 |
|---|---|---|
| DocScrutinizer | sounds feasible, yes | 00:00 |
| MNZ | except for media apps that do PA directly and not ALSA's pulse plugin | 00:01 |
| DocScrutinizer | I don't know enough bout PA to comment on the best way to marry it with ALSA/ACI | 00:04 |
| MNZ | you know about the alsa 'pulse' plugin? | 00:04 |
| DocScrutinizer | sorry, ttyl | 00:05 |
| MNZ | np, c ya | 00:05 |
| DocScrutinizer | dinner, if I find anything yet | 00:05 |
| *** silbo__ has quit IRC | 00:06 | |
| *** csaavedra has quit IRC | 00:14 | |
| *** MNZ has quit IRC | 00:47 | |
| *** SpeedEvil has quit IRC | 01:28 | |
| *** SpeedEvil1 has joined #maemo-devel | 01:28 | |
| *** SpeedEvil1 is now known as SpeedEvil | 01:30 | |
| *** swc|666 has joined #maemo-devel | 01:44 | |
| *** SpeedEvil has quit IRC | 02:30 | |
| *** SpeedEvil has joined #maemo-devel | 02:30 | |
| *** alvaro__ has quit IRC | 02:33 | |
| *** GeneralAntilles has quit IRC | 02:49 | |
| *** GeneralAntilles has joined #maemo-devel | 02:51 | |
| *** matnel has quit IRC | 03:33 | |
| *** lcuk has quit IRC | 03:45 | |
| *** swc|666 has quit IRC | 03:49 | |
| *** matnel has joined #maemo-devel | 04:01 | |
| *** swc|666 has joined #maemo-devel | 06:13 | |
| *** kamui__ has joined #maemo-devel | 07:17 | |
| *** shinkamui has quit IRC | 07:22 | |
| *** DocScrutinizer has quit IRC | 07:33 | |
| *** DocScrutinizer has joined #maemo-devel | 07:33 | |
| *** tealbird has joined #maemo-devel | 07:44 | |
| *** septiq has joined #maemo-devel | 08:07 | |
| *** ShadSEC has quit IRC | 10:03 | |
| *** ShadSEC has joined #maemo-devel | 10:09 | |
| *** ShadSEC has quit IRC | 10:13 | |
| *** ShadSEC has joined #maemo-devel | 10:14 | |
| *** ShadSEC has quit IRC | 10:22 | |
| *** ShadSEC has joined #maemo-devel | 10:29 | |
| *** amigadave has joined #maemo-devel | 10:30 | |
| *** ShadSEC has quit IRC | 10:35 | |
| *** csaavedra has joined #maemo-devel | 10:45 | |
| *** jacekowski has quit IRC | 10:45 | |
| *** ShadSEC has joined #maemo-devel | 10:48 | |
| *** jacekowski has joined #maemo-devel | 10:50 | |
| *** gopal has joined #maemo-devel | 11:09 | |
| *** ShadSEC has quit IRC | 11:09 | |
| gopal | hi, is there any limit on the size of the file an application is allowed to create in /tmp partition? | 11:10 |
| *** ShadSEC has joined #maemo-devel | 11:14 | |
| gopal | when i created my files in my home folder it was created properly...but in the tmp folder there was an error...only some parts of the file where created | 11:18 |
| *** ShadSEC has quit IRC | 11:33 | |
| *** amigadave has quit IRC | 11:38 | |
| *** ShadSEC has joined #maemo-devel | 11:41 | |
| *** amigadave has joined #maemo-devel | 11:45 | |
| *** boogeyman has joined #maemo-devel | 11:46 | |
| *** swc|666 has quit IRC | 11:48 | |
| *** ShadSEC has quit IRC | 11:56 | |
| *** MNZ has joined #maemo-devel | 11:57 | |
| *** tron71 has joined #maemo-devel | 12:23 | |
| *** ptl has quit IRC | 12:35 | |
| *** ShadSEC has joined #maemo-devel | 12:38 | |
| *** ShadSEC has quit IRC | 12:43 | |
| *** achipa has joined #maemo-devel | 12:43 | |
| *** csaavedra has quit IRC | 12:44 | |
| *** csaavedra has joined #maemo-devel | 12:44 | |
| *** ptl has joined #maemo-devel | 12:46 | |
| *** ptl has quit IRC | 12:46 | |
| *** ptl has joined #maemo-devel | 12:46 | |
| *** tron71 has quit IRC | 13:03 | |
| *** septiq has quit IRC | 13:13 | |
| *** ShadSEC has joined #maemo-devel | 13:16 | |
| *** ShadSEC has quit IRC | 13:20 | |
| *** silbo__ has joined #maemo-devel | 13:35 | |
| *** ShadSEC has joined #maemo-devel | 13:39 | |
| *** madsy_ has joined #maemo-devel | 13:49 | |
| *** madsy has quit IRC | 13:49 | |
| *** ShadSEC has quit IRC | 13:52 | |
| *** ShadSEC has joined #maemo-devel | 13:59 | |
| *** ShadSEC has quit IRC | 14:06 | |
| *** ShadSEC has joined #maemo-devel | 14:18 | |
| *** silbo__ has quit IRC | 14:29 | |
| *** silbo__ has joined #maemo-devel | 14:35 | |
| *** ShadSEC has quit IRC | 14:39 | |
| *** ShadSEC has joined #maemo-devel | 14:44 | |
| *** ShadSEC has quit IRC | 14:49 | |
| *** lmoura_ has joined #maemo-devel | 14:53 | |
| *** ShadSEC has joined #maemo-devel | 14:56 | |
| *** lmoura has quit IRC | 14:56 | |
| *** jarkkom has joined #maemo-devel | 14:58 | |
| *** ShadSEC has quit IRC | 15:10 | |
| *** jarkkom has quit IRC | 15:13 | |
| *** lmoura_ has quit IRC | 15:18 | |
| *** ShadSEC has joined #maemo-devel | 15:18 | |
| *** jarkkom has joined #maemo-devel | 15:18 | |
| *** lizardo has joined #maemo-devel | 15:28 | |
| *** lmoura_ has joined #maemo-devel | 15:29 | |
| *** gopal has quit IRC | 15:40 | |
| *** alvaro__ has joined #maemo-devel | 15:46 | |
| *** qknight_ has joined #maemo-devel | 16:10 | |
| *** septiq has joined #maemo-devel | 16:13 | |
| *** skrr has joined #maemo-devel | 16:17 | |
| DocScrutinizer | MNZ: (acihooklib, ACI basics) <copy from another chan> DocScrutinizer: idea being the user apps using ALSA snd_open() and snd_close() don't do this with "ALSA:default" but come with their own .alsarc.d/* alsaconfig files to include to ALSA .alsarc and defining a unique ALSA audio device for the app. Then with acihooklib and ALSA hooks plugin you define arbitrary commands that get executed whenever such a unique individual audio dev is | 16:26 |
| DocScrutinizer | snd_open()'ed or close()'ed | 16:26 |
| MNZ | DocScrutinizer, Why the unique alsa device? | 16:38 |
| DocScrutinizer | because then you get e.g. a softvol for each app for free, and also you probably want to assign app specific commands assigned to the unique device's unique acihooklib/hooks plugin | 16:40 |
| DocScrutinizer | of course several mp3 players might just use one generic audiodev like musicplayback:0.0 | 16:42 |
| MNZ | well most alsa apps simply open the default device and have config options to change to another device | 16:43 |
| MNZ | And that's what we have on maemo, the default device being a virtual device (pulseaudio plugin, dumps audio to PA which does its thing and dumps back to hw:0,0) | 16:43 |
| DocScrutinizer | sure that's not really the topic here though | 16:43 |
| DocScrutinizer | yepyep | 16:44 |
| DocScrutinizer | the idiocy being when the app doesn't allow for any other device than ALSA:default | 16:44 |
| DocScrutinizer | but you can 'fix' that by defining a thing like "#include $APPS_OWN_AUDIODEV" in global .asoundrc, and start app with "APPS_OWN_AUDIODEV=/path/to/my/asoundrcfile app" | 16:46 |
| DocScrutinizer | then redefining default inside this $APPS_OWN_AUDIODEV file | 16:47 |
| DocScrutinizer | don't ask me how to use that scheme for generic PA apps | 16:47 |
| MNZ | :D clever | 16:48 |
| DocScrutinizer | MNZ: I've been thinking about that shit for 2+ years until acihooklib finally hitting the world | 16:48 |
| MNZ | what does the default alsa hook functionality offer? | 16:50 |
| DocScrutinizer | would be a sad and disappointing result if it only were some simple "use dmix instead of PA" | 16:50 |
| DocScrutinizer | default alsa hook function is to set controls like alsactl does | 16:50 |
| DocScrutinizer | or alsamixer | 16:51 |
| DocScrutinizer | even locking, and restoring on device close | 16:51 |
| DocScrutinizer | this alone is pretty powerful a tool | 16:51 |
| DocScrutinizer | add acihooklib and you can do virtually everything, just using ALSA and forget PA and other weird approaches | 16:52 |
| MNZ | actually my current thought on this is 2 softvols dumping into a dmix. 1 softvol is set to default, and 1 is set as PA's sink. If PA ever opens this softvol, the other one is completely muted. So all calls and system stuff goes through PA (can't change that) but media (mafw stuff and native alsa) goes through the other softvol | 16:52 |
| DocScrutinizer | sounds sensible and exactly along my own thoughts | 16:53 |
| DocScrutinizer | MNZ: for an alternative to PA's much praised hotswitching of audio cards (e.g. from speaker to headset): you can split a downstream into 2 duplicates, run each one thru a softvol, and let them output to e.g. speaker and headset same time | 16:57 |
| DocScrutinizer | plug-detect daemon of wired headset simply would mute the speaker softvol (first raw approach) | 16:58 |
| *** achipa has quit IRC | 16:58 | |
| MNZ | Actually speaker amp is turned on/off in the driver on plug detection as well | 16:59 |
| DocScrutinizer | heh, so finally no nead to care about softvol muting then :-D | 16:59 |
| DocScrutinizer | need* | 16:59 |
| DocScrutinizer | though I really don't apreciate that concept. E.G ringtone playback when headphones plugged in should ramp up volume of ringtone via headset first, and after some 5..10s should start concurrent playback via speakers - you might have dropped the device anywhere without unplugging the headset. Or just have the headset 'unplugged' from your ears | 17:02 |
| MNZ | I've noticed this in the PA configs | 17:03 |
| MNZ | there are two alsa playback devices, and only on ringing are both of them used, otherwise audio is dumped only to one of them | 17:04 |
| MNZ | I'm unsure yet what the other one is | 17:04 |
| DocScrutinizer | (btw seems we're now entering fields where even PA isn't as versatile as ALSA + ACI :-D ) | 17:04 |
| MNZ | hehe | 17:04 |
| DocScrutinizer | and the most funny part: all this done by mere understanding and exploiting existing options in ALSA, plus some config file tweaking, plus some 100lines of code for a lib.so specified and coded by a weirdo (me) with some help of a brilliant kernel hacker (paul) | 17:10 |
| MNZ | heh fun times :D | 17:12 |
| DocScrutinizer | now add to this a small program called by acihooklib (or a acihooklib extension) that talks to a central resource arbiter and device state management entity ( :-P ) via d-bus, and knows how to pass arbitrary signals and/or keypress events etc to PPID (the audio app parent process), like "P" keyevent for 'pause' to mp3player... | 17:19 |
| DocScrutinizer | nota bene, still all this needs ZERO customizing of original audio application, except setting audio device config correctly. No special maemo sourcecode version, implementing messing around with d-bus calls to MCE to avoid e.g. screen blanking during video playback. All that can be done with original unmodded app plus ACI | 17:22 |
| DocScrutinizer | which has been my major goal when inventing this: keep apps unchanged, avoid need for any platform specific modifications | 17:24 |
| MNZ | Was this work originally with the purpose of removing PA from maemo? | 17:25 |
| DocScrutinizer | then came PA on virtually all desktop distros, and users bitching about all formerly nicely working ALSA based apps now need to learn PA, as PA's ALSA compatibility plugin is resulting in all sorts of audio problems | 17:26 |
| DocScrutinizer | MNZ: nope, this work was targeted direction sane Openmoko audio system | 17:26 |
| DocScrutinizer | Openmoko discarded PA after some 8 weeks as it had performance issues and ate large amounts of CPU X-P | 17:27 |
| DocScrutinizer | so PA never been on by dish for that | 17:28 |
| DocScrutinizer | my* | 17:28 |
| ShadowJK | heh, I never got alsa to work any better without pulse than what it does with alsa's pulse plugin | 17:34 |
| DocScrutinizer | ShadowJK: maybe you never seriously tried? | 17:35 |
| ShadowJK | though setting apps to usw hw:0,0 or something directly worked awesomely, though only one app at a time | 17:35 |
| DocScrutinizer | as in "create your own customized .asoundrc" etc | 17:35 |
| MNZ | I dunno but I never actually *tried* to get alsa working, because it just does. Last I recall messing with asound.conf on my laptop/PC was several years ago on LFS (linux from scratch) :/ | 17:36 |
| DocScrutinizer | :-)) | 17:37 |
| MNZ | ShadowJK, just set programs to use the 'default' device. A dmix plugin is created automagically now | 17:37 |
| DocScrutinizer | MNZ: that largely depends on distro maintainers' effort to correctly support your particular hardware in asoundrc | 17:38 |
| DocScrutinizer | and lib/alsa/config | 17:38 |
| DocScrutinizer | or whatever it's named | 17:38 |
| *** madsy_ has quit IRC | 17:39 | |
| MNZ | it's not distro maintainer's job even, the alsa folks do that stuff | 17:39 |
| DocScrutinizer | :nod: | 17:39 |
| *** madsy has joined #maemo-devel | 17:39 | |
| ShadowJK | yeah well, point me to the documentation and I'll give it a go :-) | 17:39 |
| MNZ | I don't even HAVE asound.conf/.asoundrc on my current installation :D | 17:39 |
| ShadowJK | the dmix plugin randomly hangs for me :/ | 17:39 |
| DocScrutinizer | hmmm | 17:40 |
| DocScrutinizer | anyway documentation is ALSA's major flaw, admittedly | 17:40 |
| *** amigadave has quit IRC | 17:41 | |
| DocScrutinizer | I started there: http://alsa.opensrc.org/.asoundrc | 17:41 |
| MNZ | for dmix http://alsa.opensrc.org/index.php/Dmix | 17:41 |
| DocScrutinizer | http://www.alsa-project.org/~jfulmer/alsa-faq.html | 17:42 |
| DocScrutinizer | http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m.html | 17:43 |
| DocScrutinizer | http://www.alsa-project.org/alsa-doc/alsa-lib/pcm_plugins.html | 17:43 |
| ShadowJK | I also had latency reporting and buffer fill reporting issues with dmix | 17:43 |
| ShadowJK | the values reported were like "full, full, full, full, empty" :/ | 17:44 |
| DocScrutinizer | sorry, I don't get the point of latency reporting | 17:44 |
| DocScrutinizer | and yes, ther's some problems there - been at least. See twinkle audio_device.c for some 10 lines dealing with that | 17:45 |
| ShadowJK | the length of audio between the sample playing and the last sample in the buffer | 17:45 |
| DocScrutinizer | why would you want to know? | 17:46 |
| ShadowJK | Because if dmix is holding 5 seconds of audio, or even .5 seconds of audio, I want to know, so that I can delay video by that amount, so that sound and lip movement are synchronized | 17:47 |
| DocScrutinizer | there's fillup threshold and lower-threshold you can specify when your process gets interrupted by ALSA device's ring buffer management | 17:47 |
| DocScrutinizer | ShadowJK: ALSA isn't designed to work that way aiui. define your buffers in a way they meet your needs | 17:48 |
| *** septiq has quit IRC | 17:49 | |
| DocScrutinizer | ALSA is driven by audio hw card's clock, not by app process' timers | 17:49 |
| DocScrutinizer | so the point where timing is correct is the speaker output, and you just fill ahead the buffers, while starting audio and video playback in sync and then forget about it | 17:50 |
| ShadowJK | In order to display video at the same rate as the audio hw clock, you need to know how fast the audio hw clock is running | 17:51 |
| DocScrutinizer | I guess there's other ways to probe that than latency value polling | 17:51 |
| ShadowJK | snd_pcm_delay() is awesome when talking to hw:0,0 (or whatever the syntax is), but when dmix gets in the middle, the returned values become increasingly useless :/ | 17:52 |
| DocScrutinizer | of course | 17:52 |
| DocScrutinizer | that's an obvious system imanent property | 17:52 |
| jacekowski | you have to love linux sound system | 17:52 |
| DocScrutinizer | anyway it's really easy to define a audio device plugin stack in asoundrc, that guarantees any arbitrary maximum latency. System load will increase accordingly to lower buffer sizes / lower latency. So usually you just use a plugin stack defined in a way to meet your latency requirements. For video playback I'd guess that's somewhere around 50..100ms | 17:55 |
| DocScrutinizer | and no need for snd_pcm_delay() | 17:56 |
| DocScrutinizer | :-) | 17:56 |
| ShadowJK | I don't actually care about maximum latency or minimum latency. It can be whatever it wants, it can even change, I don't care. I just want an accurate figure of what it is | 17:56 |
| ShadowJK | iirc it was like 2-5 seconds with dmix :) | 17:57 |
| DocScrutinizer | just don't expect 'alsa:default' to meet your needs, and try to work around it with snd_pcm_delay() when finding it actually doesn't | 17:57 |
| DocScrutinizer | as that'S quite sure the wrong way to go | 17:57 |
| DocScrutinizer | ShadowJK: your statement is paradox | 17:58 |
| ShadowJK | No it's not | 17:58 |
| DocScrutinizer | either you care about latency, then deal with it in a reasonable way (by using a properly defined plugin stack), or you don't care, then do not whine about whatever your default setup is doesn't meet your (allegedly nonexistent) latency requirements | 17:59 |
| ShadowJK | I don't have latency requirements as such. It's fine even if the buffer is 60 seconds big (and even nicer if the entire buffer can be paused or thrown away). | 18:01 |
| DocScrutinizer | it can | 18:01 |
| DocScrutinizer | obviously not for dmixed audio streams though, as that would mean you're possibly discarding output of another process mixed in | 18:02 |
| ShadowJK | You only need low latency for realtime stuff, like telephony or, uh, if you want to emulate a karaoke player | 18:02 |
| DocScrutinizer | checkout twinkle! after v0.4.1 +- there's never been any complaints about latency, until PA came messing up stuff | 18:04 |
| DocScrutinizer | ShadowJK: and btw in my book telephony with a tolerable max latency of maybe 500ms is all but realtime | 18:07 |
| ShadowJK | alsa-pulse seems to give me about 500ms | 18:08 |
| DocScrutinizer | so that's any great or what? | 18:09 |
| ShadowJK | Well it's positive that each call to snd_pcm_delay() actually reports a different value | 18:14 |
| ShadowJK | and not the same value for half a second then jumping to a new value ;p | 18:14 |
| *** pH5 has joined #maemo-devel | 18:14 | |
| DocScrutinizer | that's not what it's supposed to do, so it's actually positive | 18:15 |
| DocScrutinizer | and - once again - I don't see the need for using snd_pcm_delay() usually, and I guarantee it's useless for plugin stacked audio devices | 18:16 |
| DocScrutinizer | it's not the recommended way to deal with the issue | 18:16 |
| DocScrutinizer | you can't complain about object destructor doesn't work correctly in assembler. Different domain, different paradigm | 18:17 |
| DocScrutinizer | ALSA obviously wasn't designed to use snd_pcm_delay() on plugin stacks, and I'd say it's no big loss as there are better ways to deal with the issue than that | 18:19 |
| DocScrutinizer | calling snd_pcm_delay() at top of a plugin stack and then trying to adjust audio(!) according to the results (even when they were of any meaning and accuracy) is like pushing a rope | 18:21 |
| DocScrutinizer | let's say you're using a very complicated ALSA plugin stack with a lot of buffering to playback audio of a video. You get all parameters of the stack on opening the audio device, you can rather precisely estimate what's your min and max latency (say 500ms min, 600ms max). You have to live with the 'jitter' of 20% (or define a better audio plugin stack which yields better jitter and lower latency). You start video playback in sync with | 18:30 |
| DocScrutinizer | audio playback, after filling audio buffers. Now when you playback for 30min, maybe clock source of audio hw has some drift, and you occasionally detect you can't fill buffers with the expected data rate, and you sit on one buffer frame of 25ms you have 'spare' as your video is ahead due to audio clock being a tad slow. What do you do? Obviously you need to insert a duplicate frame to VIDEO to get it back in sync to your audio, and | 18:30 |
| DocScrutinizer | fine you are again | 18:31 |
| DocScrutinizer | if you're smart you will insert that dup frame after detecting 2 rather identical original frames in sequence, as then you'll not see any artifacts in moving objects | 18:36 |
| DocScrutinizer | if you're even smarter you tune your framerate slightly to adapt to the audio clock source freq | 18:36 |
| DocScrutinizer | or you tune your audio sample generation rate to compensate for the audio hw clock slightly off to what you expected it was | 18:38 |
| DocScrutinizer | dropping audio buffer frames is a bad idea, as is inserting filler frames (except when silence) | 18:39 |
| ShadowJK | I wouldn't try to adjust audio as a result of snd_pcm_delay | 18:40 |
| DocScrutinizer | WAAAAAH, would you please stop debating about snd_pcm_delay | 18:41 |
| DocScrutinizer | where in my above monolog was snd_pcm_delay ? | 18:41 |
| DocScrutinizer | except in "dont use snd_pcm_delay" in prolog | 18:42 |
| ShadowJK | system clock and audio clock are like +- 10% of eachother, so just starting audio and video at the same time and hoping for the best doesn't work | 18:42 |
| ShadowJK | "calling snd_pcm_delay() at top of a plugin stack and then trying to adjust audio(!) according to the results" <- that | 18:42 |
| DocScrutinizer | seen next line and rest of this line???? | 18:42 |
| DocScrutinizer | (even when they were of any meaning and accuracy) is like pushing a rope | 18:44 |
| ShadowJK | The way that video players do it is something like this for 25fps video, 44100hz audio: Show first frame, start playing audio. decode next frame, Wait until audio drivers report that 1764 samples have been played, display the decoded frame, wait for audio drivers to report another 1764 samples played | 18:44 |
| DocScrutinizer | umm, so you say as they are doing BS we need to do BS as well? | 18:45 |
| ShadowJK | the video rate (relative to system clock here, mind) is adjusted to audio clock. Audio samplerate isn't adjusted and isn't resampled | 18:46 |
| ShadowJK | and audio frames aren't inserted or dropped | 18:46 |
| DocScrutinizer | umm, so where's the problem? evaluate true audio clock rate (or, more precisely, apparent true audio clock rate as seen from a closed system based on inaccurate system clock) - e.g playback 10s of silence and see what this gets you. then calculate all your remaining numbers based on that, and fine you are | 18:48 |
| DocScrutinizer | and for all I know almost every sw video player has a setting to adjust audio-video skew by +-some-seconds | 18:49 |
| DocScrutinizer | so you absolutely don't need short latency. And aiui you're just on my line for the rest of the procedure | 18:50 |
| ShadowJK | sure.. but if there's a A-V delay that's constant throughout, then it's either a problem in parsing the file, or you get an error from the delay reporting that's constant and non-changing, which is annoying, but not the end of the world | 18:50 |
| ShadowJK | A constant error is easier to deal with than a $real-$reported value that's non-constant and has a sawtooth waveform :-) | 18:51 |
| DocScrutinizer | delay reporting in alsa aiui means knowing your plugin stack | 18:51 |
| DocScrutinizer | the sawtooth is exactly what's really going on while ringbuffer emties fradually, then is filled by another chunk | 18:52 |
| DocScrutinizer | that's the jitter you have to live with | 18:52 |
| ShadowJK | So I think this is my original point, that once plugins get involved, you don't know if you get good data anymore, like alsa wasn't designed to keep it.. | 18:53 |
| DocScrutinizer | though you're free to make it as small as you like, at expense of higher system load for smaller biffers | 18:53 |
| ShadowJK | pulseaudio is a horrible CPU hog and likes to hang apps and itself daily, but atleast it seems designed to not throw away stuff the sound system is reporting :-) | 18:54 |
| DocScrutinizer | from inspecting and knowing your plugin stack you know the abs max/min values aka jitter you'll encounter | 18:54 |
| *** septiq has joined #maemo-devel | 18:57 | |
| DocScrutinizer | btw for things like voip the situation is more complicated as you have two clock sources, one in your local audiio hw and one in far end hw. In that case you can't avoid occasional audio frame dropping or inserting, to sync with the far end | 18:58 |
| DocScrutinizer | SIPphones not dealing with this are the ones that see occasional "lad is increasing to minutes, after hours of call duration" bugs | 18:59 |
| DocScrutinizer | s/lad /lag / | 18:59 |
| DocScrutinizer | for meadi playback you're happily rif of that issue | 18:59 |
| ShadowJK | the "jitter" is one sample big when you deal directly with hw:0,0, even if the buffer setup is 16384 samples * 8 buffers :-) | 19:00 |
| DocScrutinizer | media | 19:00 |
| DocScrutinizer | err what? | 19:00 |
| ShadowJK | Yep, what I said :-) | 19:02 |
| DocScrutinizer | sorry don't follow - which 'jitter'? | 19:02 |
| DocScrutinizer | the values repited by snd_pcm_delay ? | 19:03 |
| DocScrutinizer | reported | 19:03 |
| ShadowJK | yeah | 19:03 |
| DocScrutinizer | now that's odd | 19:03 |
| ShadowJK | obviously if you repeatedly ask how many bytes you can write to the buffer, it's 0 until it jumps to 16384 | 19:03 |
| DocScrutinizer | except if you use sample by sample filling of buffer | 19:03 |
| DocScrutinizer | now that's exactly *not* what you said before | 19:04 |
| DocScrutinizer | it's absolutely sane | 19:04 |
| DocScrutinizer | anyway, RL is calling | 19:05 |
| DocScrutinizer | cya | 19:05 |
| DocScrutinizer | see, audio HARDWARE might have a buffer which is big enough to hold 16384. hw:0.0 is filling this buffer whenever hw tells "I'm getting out of data" - in a chunk of 16384. There quite well may be no way whatsoever to ask the audio hardware how much of that chunk actually has been sent out via D/A. That's the whole purpose of advanced audio hw, not to load burden of transferring 16bit every 1/44.000 of a second. Thats why IRQs were | 19:10 |
| DocScrutinizer | invented | 19:10 |
| DocScrutinizer | so how could you get any sawtooth like you supposed, from snd_pcm_delay() on hw:0.0? | 19:12 |
| DocScrutinizer | that's simply Heissenberg of audio | 19:13 |
| *** shinkamui has joined #maemo-devel | 19:17 | |
| DocScrutinizer | you define a Heissenberg as small as fits your needs, on setting up audio stack, and then have to live with it. no snd_pcm_delay() whatsoever will get you beyond that Heissenberg, once your audio device is set up | 19:18 |
| DocScrutinizer | you know you're in sync when starting hw playback of first filled buffer, and you know there's something not exactly to the specs not earlier than when a whole buffer size aka Heissenberg constant of audio of offset has elapsed, so that's where you are | 19:21 |
| *** kamui__ has quit IRC | 19:21 | |
| DocScrutinizer | otherwise you'd be back to polling when exactly snd_pcm_delay() is jumping, and that's just a silly way to say "I would need smaller buffer size" | 19:22 |
| *** silbo__ has quit IRC | 19:51 | |
| *** septiq_ has joined #maemo-devel | 19:57 | |
| *** septiq has quit IRC | 20:00 | |
| *** septiq_ is now known as septiq | 20:00 | |
| *** septiq has quit IRC | 20:06 | |
| *** VDVsx has joined #maemo-devel | 20:31 | |
| *** swc|666 has joined #maemo-devel | 21:12 | |
| *** edisson has joined #maemo-devel | 21:15 | |
| *** lmoura_ has quit IRC | 21:27 | |
| *** lmoura has joined #maemo-devel | 21:27 | |
| *** VDVsx has quit IRC | 21:45 | |
| jarkkom | anyone worked with threaded mainloop pulseaudio? I've got app that runs just fine on emulator under ubuntu but running it on actual n900 there's segfault somewhere inside libpulsecommon after app gets PA_CONTEXT_CONNECTING callback | 21:57 |
| *** shadeslayer has left #maemo-devel | 22:02 | |
| *** lcuk has joined #maemo-devel | 22:10 | |
| MNZ | DocScrutinizer, using softvol how do I get the control to show up? with | 22:12 |
| MNZ | with card "0" | 22:12 |
| MNZ | it's supposed to show with amixer -D hw:0 | 22:13 |
| DocScrutinizer | hmm, yup I'd guess so | 22:13 |
| DocScrutinizer | for me *iirc* it sometimes needed some mixer restart (kmixer) for the volume sliders (two as all alsa plugins are down- as well as upstream, except a few like dmix, dsnoop) to show up on the tabs. Also make sure they're not hidden, several mixers allow hiding controls | 22:15 |
| MNZ | I'm using amixer, a simple alsa util that just dumps controls on stdout as text | 22:15 |
| MNZ | ohhh frrriiiiigggg | 22:22 |
| *** go1dfish has quit IRC | 22:23 | |
| *** 16SAAFA93 has joined #maemo-devel | 22:24 | |
| *** ShadSEC has quit IRC | 22:27 | |
| DocScrutinizer | ohhh what? | 22:41 |
| MNZ | nvm I thought it was stale inodes or something (I had mved asound.conf and made a new one, so if it was still open by something...) | 22:42 |
| MNZ | but no, full restart and still can't get control to show up | 22:42 |
| DocScrutinizer | I have to admit I can't recall how amixer was dealing with softvol | 22:42 |
| MNZ | though the pcm registers ("aplay -L" lists it | 22:42 |
| MNZ | I have read two docs that say it should work as expected | 22:43 |
| MNZ | something fishy is happening | 22:43 |
| DocScrutinizer | err, there's been some catch, lemme think | 22:43 |
| DocScrutinizer | check if card '0' parameter is correct. | 22:44 |
| *** go1dfish has joined #maemo-devel | 22:44 | |
| MNZ | it seems to be right. I tried both "0" and 0 | 22:45 |
| MNZ | what's [iface STR] # interface of the element | 22:45 |
| DocScrutinizer | http://tech.groups.yahoo.com/group/twinklephone/message/1786 +-A thread context | 22:46 |
| *** _0x47 has joined #maemo-devel | 22:55 | |
| MNZ | ok still doesn't work, but I tried playback and it adds 20% cpu usage to mplayer XD XD | 22:57 |
| *** air has quit IRC | 23:00 | |
| DocScrutinizer | lol | 23:02 |
| MNZ | and 10% of those is resampling :D changed dmix to 44100 and instant 10% down | 23:03 |
| DocScrutinizer | btw, you're aware of the Plugin: Route & Volume ( http://www.alsa-project.org/alsa-doc/alsa-lib/pcm_plugins.html ) ? | 23:04 |
| * SpeedEvil wonders HTF you get 10% CPU on resampling. | 23:04 | |
| MNZ | SpeedEvil, I was thinking of that.... but both PA and dmix seem to require quite a bit of computing to do it | 23:06 |
| MNZ | TBH I have no idea what the computation behind this is | 23:06 |
| MNZ | DocScrutinizer, I don't get it, what does that do? | 23:06 |
| DocScrutinizer | e.g. mixes down stereo to mono; out= L*0.5 + R*0.5 | 23:07 |
| DocScrutinizer | or mono to stereo, or quattro | 23:07 |
| MNZ | is... that it? | 23:08 |
| DocScrutinizer | yep, it's all it does | 23:08 |
| ShadowJK | 48000 -> 44100 ate about 5% on a P3-733MHz with the non-stupid algorithm :/ | 23:11 |
| DocScrutinizer | good resampling is friggin expensive | 23:16 |
| DocScrutinizer | several MULADDS and maybe even trigo | 23:17 |
| DocScrutinizer | or ln | 23:17 |
| DocScrutinizer | all in real | 23:18 |
| lcuk | good resampling can be done entirely in integer | 23:18 |
| lcuk | but you need LOTS of integers ;) | 23:18 |
| DocScrutinizer | ok, ot that | 23:19 |
| DocScrutinizer | or | 23:19 |
| DocScrutinizer | and at lease int32 :-D | 23:19 |
| DocScrutinizer | darn, at least | 23:19 |
| DocScrutinizer | is alexia a co-symptom of alzheimer? | 23:20 |
| DocScrutinizer | MNZ: anyway, by all means avoid resampling whenever possible | 23:22 |
| DocScrutinizer | you MUST NOT resample multiple times for a single device | 23:22 |
| DocScrutinizer | ~2119 | 23:23 |
| DocScrutinizer | ~join!! | 23:23 |
| MNZ | Well the codec supports changing sampling rate | 23:24 |
| MNZ | alsa devices support multiple rates? | 23:24 |
| MNZ | so eg. you open and specify a rate and it passes down the rate to the hw | 23:24 |
| DocScrutinizer | it's absolutely better nevertheless to keep sampling rate at 48000 for all plugin stack, than to resample 44100 -> 48000 after dmix and whatnot running on a slightly cheaper rate | 23:25 |
| DocScrutinizer | MNZ: it does this for all usual plugins, except plug plugin, and resample plugin | 23:26 |
| MNZ | so how would I set multiple rates for dmix..? | 23:27 |
| DocScrutinizer | use aplay -v xy.wav for a nice listing of plugin stack, incl sampling rates in and out of each, buffer sizes, format etc | 23:28 |
| DocScrutinizer | connect to dmix via plug | 23:28 |
| DocScrutinizer | device uses plug:dmix:hw | 23:29 |
| DocScrutinizer | dmix and hw work with rate defined in hw, plug resamples if needed to the rate app asked for on opening the stack | 23:30 |
| *** 16SAAFA93 has quit IRC | 23:32 | |
| DocScrutinizer | pcm.xxx { | 23:32 |
| DocScrutinizer | type plug | 23:32 |
| DocScrutinizer | slave.pcm "dmix" | 23:32 |
| DocScrutinizer | } | 23:32 |
| *** pH5 has quit IRC | 23:34 | |
| DocScrutinizer | Note that the dmix plugin itself supports only a single configuration. That is, it supports only the fixed rate (default 48000), format (S16), channels (2), and period_time (125000). For using other configuration, you have to set the value explicitly in the slave PCM definition. The rate, format and channels can be covered by an additional plug plugin, but there is only one base configuration, anyway. | 23:35 |
| MNZ | ok I'm confused. So the hw supports different rates, can you outline how to exploit that? | 23:36 |
| DocScrutinizer | see, dmix needs to add/mix streams of same format. So on first invocation, the app is defining format, rate etc, and this propagates down the stack until hw, getting all sorts of modifications explicitly defined on the way. when hitting hw it asks hw about what that "plugin" supports, and if hw can do the requested rate, an ACK will propagate up the stack | 23:39 |
| villager | pc-gamer hardware supports different rates, and alsa supports it on that hardware... the n900 hardware might not support that | 23:39 |
| DocScrutinizer | for a seconds source using same dmix, the dmix and lower levels of plugins and hw are predefined | 23:39 |
| DocScrutinizer | but usually you'll define a rate in hw slave plugin | 23:40 |
| DocScrutinizer | so you always see same situation when opening same device, no matter if it's been opened concurrently by another app and what parameters that app asked for. the plug plugin between app and dmix is converting whatever the app asked for to the fixed dmix rate then | 23:42 |
| DocScrutinizer | and you know your output won't eventually be 8000 and sound like an old phone, while you asked for 44100 stereo for HiFi | 23:42 |
| MNZ | but if it's fixed like that... then how can the hardware be exploited to avoid resampling? | 23:44 |
| DocScrutinizer | that's indeed almost impossible | 23:45 |
| DocScrutinizer | but when you think about it, this could be done only for mutual exclusive use of a hw | 23:45 |
| DocScrutinizer | so no dmix involved, and any concurrent snd_open() will fail | 23:45 |
| villager | which is what caused all the pulseaudio precursors to get invented... | 23:46 |
| DocScrutinizer | so I.E. you just use hw:0.0 directly from your app, and hw will open whatever app asks, as long as it's supported by hw | 23:46 |
| MNZ | I was thinking something like first open() sets the current rate and next concurrent() open would simply resample. But that doesn't look possible | 23:49 |
| MNZ | unless we write an alsa plugin for it (and I'm not sure if it becomes possible then) | 23:49 |
| DocScrutinizer | indeed that's wha's hapening when you are using plug;dmix:hw | 23:49 |
| DocScrutinizer | without explicitly defined rates | 23:50 |
| MNZ | but I just tried without specifying rate and it simply uses 48k | 23:50 |
| DocScrutinizer | whatever rate first app asks for, propagates down the stack and sets hw rate | 23:50 |
| DocScrutinizer | for second app dmix is fixed to what frist app asked for, and plug will resample | 23:51 |
| MNZ | DocScrutinizer, but I just tried that! aplay playing 44.1k wav to plug:dmix:hw | 23:51 |
| MNZ | all of which have no rate setting, but -v tells me all are 48k | 23:51 |
| DocScrutinizer | hmm, and your hw slabe plugin has no rate specified? | 23:51 |
| MNZ | no rates whatsoever | 23:52 |
| DocScrutinizer | umm, that's weird | 23:52 |
| MNZ | not really. With no rate specified it simply sets it to a default of 48k | 23:52 |
| DocScrutinizer | maybe I got something wrong then, or there's something odd in maemo ASLA | 23:52 |
| MNZ | That opening and setting current rate thing, I think it would need a separate plugin | 23:52 |
| DocScrutinizer | can you pastebin -v please? | 23:53 |
| *** lizardo has quit IRC | 23:53 | |
| DocScrutinizer | also try specify rate for aplay explicitly | 23:54 |
| MNZ | tried that, same thing | 23:55 |
| MNZ | http://pastebin.com/5N3KMAqz | 23:55 |
| DocScrutinizer | nah, when you tell aplay to use -r 44100, then either plug is resampling to 48000, or whole stack is using 44100, or snd_open() fails | 23:56 |
| MNZ | yeah, same thing as in plug goes 44.1k | 23:56 |
| MNZ | rest is 48 | 23:56 |
| MNZ | actually, without plug and no rate settings I get a message saying 'asked for 44.1 but got 48' | 23:57 |
| DocScrutinizer | check | 23:59 |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!