similar to: ogg123: close_dsp_on_suspend and next_on_SIGUSR1 patches submission

I added a couple of functions to my copy of ao. int ao_get_driver_count(void); const char * ao_get_driver_name(int index); With these, I can get a list of drivers and give the user a choice by using radio buttons, e.g. [ ] alsa [*] oss [ ] esd [ ] null [ ] wav This is a lot nicer than just asking them to enter the name of the driver. Here's the code I added to audio_out.c: const char *

Btrfs uses anon bdevs, this is not needed. Signed-off-by: Ilya Dryomov <idryomov@gmail.com> --- fs/btrfs/volumes.c | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c index f2a4cc7..afd6a1e 100644 --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -1376,8 +1376,6 @@ int btrfs_rm_device(struct btrfs_root *root, char

Hi all, I''m seeing some unexpected behaviour in a nested model and I''m not sure if it''s a bug or if I''m doing something wrong. When assigning nested attributes, the associated object gets replaced with a new record. Example code: class Car < ActiveRecord::Base belongs_to :driver end class Car < ActiveRecord::Base belongs_to :driver end

Hi, The following controller method taking me into infinite loop. Once the update action completes I want to reload the ''index'' page. May I know why it is going into infinite loop? def update Device.find_by_id( params[:device_id] ).driver = ( params[:driver_id] == 0 ) ? nil : Driver.find_by_id( params[:driver_id] ) redirect_to :action => :index, :tab =>

Hello, I hope this is the right place to ask. I am having random lockups from the python bindings. My app has one or two threads running, the lockups only occure at one point, here is the code run as a thread def play(self): self.playing = TRUE self.output = [] self.lastplay = time.time() args = self.song_file, self.output retval =

Hi, I am running a negative binomial model using Gamlss and when I try to include random effect, I get the following message: Warning messages: 1: In vcov.gamlss(object, "all") : addive terms exists in the mu formula standard errors for the linear terms maybe are not appropriate 2: In vcov.gamlss(object, "all") : addive terms exists in the sigma formula standard

I'm having several problems with ogg123 on a FreeBSD-STABLE machine. In each case, ogg123 dumps core complaining about a bus error. 1) ogg123 plays all files at what seems like twice the correct speed. When given a SIGINT, ogg123 dumps core. This is using the program defaults, including the OSS driver. Here's a backtrace from gdb: Core was generated by `ogg123'. Program

Another one at block.c:176: --- Title: We The People Artist: DJ Lithium Presents Bitstream is 2 channel, 44100Hz Time: 58:29.07, Bitrate: 100.1 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 27207)] _vds_shared_init (v=0xbffff73c, vi=0x4024efe0, encp=0) at block.c:176 176 b->modebits=ilog2(ci->modes); (gdb) bt #0 _vds_shared_init

Why has ao been changed so that there are now two open() functions ? IMHO the original ao_open() was fine - if you wanted to set the filename for output, you could add an option via ao_append_option and if you wanted to avoid overwriting an existing file, you could stat() it yourself. Having ao_open_live() and ao_open_file() just makes more work for the user of the library for no gain, AFAICT.

Why has ao been changed so that there are now two open() functions ? IMHO the original ao_open() was fine - if you wanted to set the filename for output, you could add an option via ao_append_option and if you wanted to avoid overwriting an existing file, you could stat() it yourself. Having ao_open_live() and ao_open_file() just makes more work for the user of the library for no gain, AFAICT.

I decided to take a break from trying to get the encoding working in order to update my libraries to the latest versions I tried to build ao-python from both SRPM and tarball, and here's what I got: --- + python setup.py install --root=/var/tmp/pyao-buildroot --record=INSTALLED_FILES running install running build running build_ext building 'aomodule' extension creating build creating

Hi! There are some little inconvenience in libao-0.8.5. - The biggest is may that: the documentation and the header file declare the ao_file_extension function, which give a hint for the file extension where the device is realy a sound file. This function is missing. -An other: the alsa 0.5 and the alsa 0.9+ drivers short name. It will be better if the alsa 0.5's name will be alsa05 and the

> next_device: > + free(curDevice->Vendor); > + free(curDevice->Product); > + free(curDevice->Serial); > + free(curDevice->Bus); > usb_close(udev); > udev = NULL; > } Wouldn't it be necessary to check whether there is anything to free or not? Vendor, Product and Serial are set conditionally. In the lines upsdebugx(2, "-

I get the following error on r809 (but it looks like the code change happened here). Does HIDDevice_t need to be defined/changed in one of the headers? if gcc -DHAVE_CONFIG_H -I. -I../../drivers -I../include -I../../include -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -DINET6 -O2 -D_REENTRANT -DNETSNMP_USE_INLINE -Wall -Dlinux -I.

Hi all, I posted originally here last week: https://alioth-lists.debian.net/pipermail/nut-upsuser/2023-October/013461.html Since then, I've been building and testing from source following the instructions a helpful reply in the above thread pointed out. The original problem is I've got one of these arduino HID power devices, as a project for a DIY UPS at home. This arduino is a composite

Here is a patch to fix the compiler warnings I mentioned earlier. I've removed the byte-order changes that don't make sense. (Thanks Michael for pointing out the error!) As for the byte-order changes, since some output modules don't have the option to set the sample byte-order, I would like to standardize libao and ogg123 on native byte-order. Will this break the ao_wav.c patches

Thank you for the investigation! I've thought about this in vague terms, i.e. that numbers like this should be configurable, but did not have time to read into USB-related libraries and specs to make any more specific sense of it (and the libusb code is not mine except the recent layers of cleanup). I guess I did not even realize that there is more than the regularly mentioned "interface

Hi Heikki, So libao is currently not maintained upstream. In the appropriate IRC channels I'm lead to believe that there are better libraries out there that should be used instead. If so many debian packages didn't link against it I would seriously consider dropping it all together. It doesn't sound like it's worth anyone's time maintaining libao properly upstream. I do have

I think having this logic buried within libhid/libusb (libusb:libusb_open(), line 179 to 206) is ultimately a mistake, albeit one that I am probably responsible for. Would it make sense to confine libhid to low-level operations, and leave the decision of trying to reopen vs. retrying to open to the high-level driver, in this case usbhid-ups? I envision that the code in usbhid-ups:reconnect_ups()

Thanks for the quick reply! Ya, I'm new to all this so I didn't know this either, I was vaguely aware of USB composite devices from other projects, but never how it was all enumerated. I dug a bit more on this and I'm convinced the relationship is this: Device ??? Configuration 1 ??? Interface 1 ? ??? Endpoint 1 ? ??? Endpoint 2 ? ??? ... ??? Interface 2