summaryrefslogtreecommitdiffstats
path: root/src/modules
Commit message (Collapse)AuthorAgeFilesLines
* alsa: allow configuration of fallback device strings in profilesLennart Poettering2009-04-292-37/+90
| | | | | | This has the benefit that we can properly support ALSA devices where only the raw 'hw' device exists but no 'front' although it's a proper 2ch stereo device.
* build-system: move x11 and jack modules into subdirectoriesLennart Poettering2009-04-286-0/+0
|
* alsa: remove debug codeLennart Poettering2009-04-191-2/+0
|
* alsa: properly convert return values of snd_strerror() to utf8Lennart Poettering2009-04-195-53/+86
|
* reserve-device: allow building without D-BusErich Boleyn2009-04-191-7/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Lennart Poettering <lennart@poettering.net> wrote: > On Wed, 15.04.09 16:26, Erich Boleyn (erich@uruk.org) wrote: > > > Just noticed the new 0.9.15 release, got it building on Gentoo, and then > > found that the non-dbus build's ALSA modules appear to be broken: ... > > Is this something that can stubbed out (relatively) safely? > > Hmm, yes. As it seems I broke the build for non-dbus builds. Should be > easy to fix. Best way is probably to make the reserver wrapper mostly > a noop if D-Bus is not available. > > Please understand that I don't really focus on making every weird > combination of build deps work. So I won't fix this for you. But I am > happy to merge good patches! No problem, I was mainly looking for a hint that to your knowledge there should be no wierd side-effects from stubbing out the reserve and dbus functions inside reserve_wrapper. Thanks for said hint. ;-) Attached is a patch to include "reserve_wrapper.[ch]" in the non-dbus builds, and do said stubbing when HAVE_DBUS is not defined. It has passed moderate testing: built both versions, both pass "pulseaudio --dump-modules" with no weird messages, and the "--disable-dbus" build works and produces audio as expected in some simple tests including RTP.
* solaris: 0.9.15 solaris module build failureFinn Thain2009-04-181-1/+1
| | | | | | | | | | | | | | | | Lennart wrote, > > Hmm, yes. As it seems I broke the build for non-dbus builds. Well, you also broke the solaris module between 0.9.15-test8 and 0.9.15. Have you considered release candidates? Patch follows. It would be nice if API changes could be made without breaking things when the effort to avoid that is trivial. Finn
* bluetoth-device: be less strict on CONNECTED state to switch profileMarc-André Lureau2009-04-171-2/+7
|
* rescue-streams: when one stream move fails try to continue with the ↵Lennart Poettering2009-04-171-10/+6
| | | | remaining ones
* add a few missing initializationsv0.9.15Lennart Poettering2009-04-141-2/+2
|
* explcitly ignore return values of some functions marked with gcc's ↵Lennart Poettering2009-04-141-2/+2
| | | | warn_unused_result attribute
* core: introduce new 'reference' volume for sinksLennart Poettering2009-04-137-99/+63
| | | | | | | | | | | | | | | The reference volume is to be used as reference volume for stored stream volumes. Previously if a new stream was created the relative volume was taken relatively to the virtual device volume. Due to the flat volume logic this could then be fed back to the virtual device volume. Repeating the whole story over and over would result in a device volume that would go lower, and lower and lower. This patch introduces a 'reference' volume for each sink which stays unmodified by stream volume changes even if flat volumes are used. It is only modified if the sink volumes are modified directly by the user. For further explanations see http://pulseaudio.org/wiki/InternalVolumes
* alsa: include the alsa mixer control that is used in the property listLennart Poettering2009-04-134-4/+7
|
* alsa: store mixer controls to use in profile dataLennart Poettering2009-04-134-19/+48
| | | | | This allows us to easily use different mixer controls for analog and spdif output.
* alsa: when passing emptry mixer control name, force sw volumeLennart Poettering2009-04-131-0/+5
|
* client-conf-x11: unbreak autospawn due to stale X11 propertiesLennart Poettering2009-04-131-1/+7
| | | | | | | If the X11 property data is from the same session than the client the client may do autospawning in case the X11 property data is stale. Closes #518.
* cork-music-on-phone: make sure that we don't check the refcnt of pa_core ↵Lennart Poettering2009-04-131-1/+0
| | | | when the daemon goes down
* lirc: fix logic behind mute buttonsLennart Poettering2009-04-131-2/+2
|
* mmkbd: get rid of support for ancient kernelsLennart Poettering2009-04-131-16/+5
|
* mmkbd,lirc: make use of pa_assert_not_reached()Lennart Poettering2009-04-132-2/+2
|
* lirc, mmkbd: extend controllable volume range to PA_VOLUME_MAXLennart Poettering2009-04-132-10/+10
|
* lirc: drop lirc_in_use, it's made redundant by PA_MODULE_LOAD_ONCELennart Poettering2009-04-131-11/+0
|
* make sure we never overflow when calculating sleep timeLennart Poettering2009-04-132-4/+28
| | | | Issue pointed out by Jaroslav Kysela
* set fixed latencies at more places where appropriateLennart Poettering2009-04-106-9/+16
|
* alsa: when printing warning about bogus data from alsa include snd_pcm_dump()Lennart Poettering2009-04-104-6/+10
|
* bluetooth: when starting up HSP stream, send 2 packets first, only ↵Lennart Poettering2009-04-101-0/+6
| | | | afterwards enter one-read-one-write logic
* bluetooth: rework timing logic, properly implement latency callbacksLennart Poettering2009-04-101-41/+134
|
* bluetooth: be a bit more verbose if we exit due to bad poll() revents flagLennart Poettering2009-04-101-1/+5
|
* bluetooth: rename sco to hsp also for the userLennart Poettering2009-04-101-3/+3
|
* bluetooth: memory leak, actually free discovery struct itselfLennart Poettering2009-04-101-0/+2
|
* bluetooth: make sure to set max_requestLennart Poettering2009-04-081-2/+30
|
* make use of SO_TIMESTAMP timestamp for accuracy and leave smoother paused ↵Lennart Poettering2009-04-073-11/+62
| | | | until we have data
* mark null sink as support dynamic latencyLennart Poettering2009-04-071-1/+1
|
* adjust max_rewind/max_request whenever the latency changesLennart Poettering2009-04-071-0/+5
|
* send the source latency based on the MTU sizeLennart Poettering2009-04-071-3/+3
|
* make sure we don't apply sampling rate fixes that bring the sampling freq > ↵Lennart Poettering2009-04-061-11/+14
| | | | | | PA_RATE_MAX Fixes #525
* don't fail device reservation if the D-Bus connection is deadLennart Poettering2009-04-061-2/+9
|
* Merge branch 'master' of ssh://rootserver/home/lennart/git/public/pulseaudioLennart Poettering2009-04-059-14/+58
|\
| * initialize sound cards only after the 'control' object appearedLennart Poettering2009-04-041-5/+25
| |
| * refuse to initialize on modem devicesLennart Poettering2009-04-044-0/+24
| |
| * various spelling fixesMaarten Bosmans2009-04-046-8/+8
| |
| * Merge branch 'master' of ssh://rootserver/home/lennart/git/public/pulseaudioLennart Poettering2009-04-031-4/+4
| |\
| * | downgrade a few messagesLennart Poettering2009-04-031-1/+1
| | |
* | | Modify smoothing code to make cubic interpolation optional and allow 'quick ↵Lennart Poettering2009-04-058-23/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fixups' on resuming The primary reason for this change is to allow time graphs that do not go through the origin and hence smoothing starting from the origin is not desired. This change will allow passing time data into the smoother while paused and then abruptly use that data without smoothing using the 'quick fixup' flag when resuming. Primary use case is allowing recording time graphs where the data recorded originates from a time before the stream was created. The resulting graft will be shifted and should not be smoothened to go through the origin.
* | | properly account for seeks in the requested_bytes counterLennart Poettering2009-04-012-3/+3
| |/ |/|
* | use machine id instead of hostname to identify local connectionsLennart Poettering2009-04-011-4/+4
|/
* fix buffer defaultsLennart Poettering2009-03-311-3/+3
|
* handle buffer_attr changed messages properlyLennart Poettering2009-03-311-1/+49
|
* revive solaris moduleFinn Thain2009-03-311-44/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On Wed, 4 Mar 2009, Lennart Poettering wrote: [snip] > > This patch disables link map/library versioning unless ld is GNU ld. > > Another approach for solaris would be to use that linker's -M option, > > but I couldn't make that work (due to undefined mainloop, browse and > > simple symbols when linking pacat. I can post the errors if anyone is > > intested.) > > The linking in PA is a bit weird since we have a cyclic dependency > between libpulse and libpulsecommon which however is not explicit. Could that affect the pacat link somehow? What are the implications for client apps that link with the non-versioned libraries I've been building on solaris? [snip] > > struct userdata { > > pa_core *core; > > @@ -87,15 +92,24 @@ struct userdata { > > > > pa_memchunk memchunk; > > > > - unsigned int page_size; > > - > > uint32_t frame_size; > > - uint32_t buffer_size; > > - unsigned int written_bytes, read_bytes; > > + int32_t buffer_size; > > + volatile uint64_t written_bytes, read_bytes; > > + pa_mutex *written_bytes_lock; > > Hmm, we generally try do do things without locking in PA. This smells as > if it was solvable using atomic ints as well. > > Actually, looking at this again I get the impression these mutex are > completely unnecessary here. All functions that lock these mutexes are > called from the IO thread so no locking should be nessary. > > Please don't use volatile here. I am pretty sure it is a misuse. Also > see http://kernel.org/doc/Documentation/volatile-considered-harmful.txt > which applies here too I think. OK, I've removed the locks. For some reason I thought that the get_latency function was called from two different threads. > > +static void sink_set_volume(pa_sink *s) { > > + struct userdata *u; > > + audio_info_t info; > > + > > + pa_assert_se(u = s->userdata); > > + > > + if (u->fd >= 0) { > > + AUDIO_INITINFO(&info); > > + > > + info.play.gain = pa_cvolume_avg(&s->virtual_volume) * AUDIO_MAX_GAIN / PA_VOLUME_NORM; > > + assert(info.play.gain <= AUDIO_MAX_GAIN); > > I'd prefer if you'd use pa_cvolume_max here instead of pa_cvolume_avg() > because this makes the volume independant of the balance. > > > - info.play.error = 0; > > + info.play.gain = pa_cvolume_avg(&s->virtual_volume) * AUDIO_MAX_GAIN / PA_VOLUME_NORM; > > + assert(info.play.gain <= AUDIO_MAX_GAIN); > > Same here. (i.e. for the source) Done and done. > > + if (u->sink->thread_info.rewind_requested) > > + pa_sink_process_rewind(u->sink, 0); > > This is correct. > > > > > err = ioctl(u->fd, AUDIO_GETINFO, &info); > > pa_assert(err >= 0); > > Hmm, if at all this should be pa_assert_se(), not pa_assert() (so that > it is not defined away by -DNDEBUG). However I'd prefer if the error > would be could correctly. (I see that this code is not yours, but > still...) Done. > > + case EINTR: > > + break; > > I think you should simply try again in this case... Done. > > + case EAGAIN: > > + u->buffer_size = u->buffer_size * 18 / 25; > > + u->buffer_size -= u->buffer_size % u->frame_size; > > + u->buffer_size = PA_MAX(u->buffer_size, (int32_t)MIN_BUFFER_SIZE); > > + pa_sink_set_max_request(u->sink, u->buffer_size); > > + pa_log("EAGAIN. Buffer size is now %u bytes (%llu buffered)", u->buffer_size, buffered_bytes); > > + break; > > Hmm, care to explain this? EAGAIN happens when the user requests a buffer size that is too large for the STREAMS layer to accept. We end up looping with EAGAIN every time we try to write out the rest of the buffer, which burns enough CPU time to trip the CPU limit. So, I reduce the buffer size with each EAGAIN. This gets us reasonably close to the largest usable buffer size. (Perhaps there's a better way to determine what that limit is, but I don't know how.) > > + > > + pa_rtpoll_set_timer_absolute(u->rtpoll, xtime0 + pa_bytes_to_usec(buffered_bytes / 2, &u->sink->sample_spec)); > > + } else { > > + pa_rtpoll_set_timer_disabled(u->rtpoll); > > } > > Hmm, you schedule audio via timers? Is that a good idea? Perhaps not. I won't know until I test on more hardware. But, given that we have rt priority and high resolution timers on solaris, I think it is OK in theory... The reason I used a timer was to minimise CPU usage and avoid the CPU limit. Recall that getting woken up by poll is not an option for playback unfortunately. We can arrange for a signal when the FD becomes writable, but that throws out the whole buffer size concept, which acts to reduce latency. > That really only makes sense if you have to deal with large buffers and > support rewinding. I've implemented rewind support, but I'm still not sure that I have understood the concept; I take it that we "rewind" (from the point-of-view of the renderer, not the sink) so that some rendered but as yet unplayed portion of the memblock/buffers can then be rendered again? > Please keep in mind that the system clock and the sound card clock > deviate. If you use the system timers to do PCM scheduling ou might need > a pa_smoother object that is able to estimate the deviation for you. Actually, in an earlier version I did use a smoother (after reading about that in the wiki). But because of the non-monotonic sample counter (bug?) I decided that it probably wasn't worth the added complexity so I removed it. I'll put the smoother back if I can figure out the problem with the sample counter. > > > + u->frame_size = pa_frame_size(&ss); > > > > - if ((fd = open(p = pa_modargs_get_value(ma, "device", DEFAULT_DEVICE), mode | O_NONBLOCK)) < 0) > > + u->buffer_size = 16384; > > It would appear more appropriate to me if the buffer size is adjusted by > the sample spec used. Done. > One last thing: it would probably be a good idea to allocate a pa_card > object and attach the sink and the source to it. It is possible to open /dev/audio twice by loading the solaris module twice -- once for the sink (passing record=0) and once for source (passing playback=0), thus giving seperate threads/LWPs for source and sink. It might be misleading to allocate two cards in that situation? > Right now pa_cards are mostly useful for switching profiles but even if > you do not allow switching profiles on-the-fly it is of some value to > find out via the cards object which source belongs to which sink. > > Otherwise I am happy! > > Thanks for your patch! I'd be thankful if you could fix the issues > pointed out and prepare another patch on top of current git! No problem. Patch follows. It also includes a portability fix for pa_realpath and a fix for a bug in the pa_signal_new() error path that causes signal data be freed if you attempt to register the same signal twice. > I hope I answered all your questions, Your answers were very helpful, thanks. Finn > > Lennart > >
* Specifying ALSA mixer controlKyle Cronan2009-03-316-8/+19
| | | | | | | | | | | | | | | | | | | | | | | | | On Fri, Mar 27, 2009 at 7:21 AM, Lennart Poettering <lennart@poettering.net> wrote: >> I tried installing the latest git sources on my Ubuntu Jaunty box but >> it just broke sound in all my applications.  For my own purposes, I'm >> going to need to start with the Ubuntu-patched 0.9.14.  However, if >> you are willing to accept this patch I will forward port it so that it >> applies to the latest sources.  It's a completely harmless change, so >> why not apply it? > > Yes, I am happy to apply it. Could you please update it for current git? > Great. An updated patch is attached. For symmetry, I added this option to the alsa source module as well. The Ubuntu folks have customized pulse so much that it is difficult for me to get this version working on my system. For this patch I have only made sure that it compiles. But it does pretty much the same thing as the one for 0.9.14, which is working great for me. Thanks, Kyle
* explain ff7033c11d9248fe837204b03c8397231dc511feLennart Poettering2009-03-311-0/+3
|