similar to: ogg123 remote interface

Hi, I have made a small patch for enabling repeating in ogg123. It adds the parameter "--repeat n" or "r n" where n indicates how many times it repeats the playlists. Zero in forever. Apply it if you like, I find it very convenient. -- Regards Niels Sandmann Jabber: sandmann@jabber.dk, Email: sandm@nn.dk -------------- next part -------------- Only in ogg123: .deps Only in

Hi Here is another patch regarding time in ogg123 which is more controvercial than the other one I send some days ago. (see attachment) When working with Daisy/SMIL [1] files it would be helpfull if the user could stop play at a specific time. Currently .ogg files are not allowed in the Daisy format but that will hopefully happen one day if I work hard at it. A clip in a Daisy file could look

Hi I've found bugs in vorbis-tools and wrote this patch to fix them: 1st part is to fix single-channel flac files. 2nd part fixes a problem with thread race causing lockup if you press Ctrl-C Ctrl-C sets sig_request.cancel, buffer thread exits if it sees sig_request.cancel However, if Ctrl-C was pressed here do { if (nthc-- == 0) { ----------------> Ctrl-C

----- Forwarded message from Don Armstrong <don@donarmstrong.com> ----- Date: Thu, 30 Sep 2004 16:19:41 -0700 From: Don Armstrong <don@donarmstrong.com> Resent-From: Don Armstrong <don@donarmstrong.com> To: submit@bugs.debian.org Subject: Bug#274301: libflac4 segfaults on corrupt flac files Severity: normal Package: libflac4 Version: 1.1.0-11 Running ogg123 on

The patch below adds: - acinclude.m4: A new macro A_FUNC_SMMAP to check that sharing pages through mmap() works. This is taken from Joerg Schilling's star. - configure.in: A_FUNC_SMMAP - ogg123/buffer.c: If we have a working mmap(), use it to create a region of shared memory instead of using System V IPC. Works on BSD. Should also work on SVR4 and offspring (Solaris), and Linux.

Hi I have helped a user with a little patch for ogg123. He uses ogg123 for very big files, often more than an hour (blind books). When he breaks the book and later on want to go back to the same chapter, it is a little troublesome to calculate the seconds. Minutes is much more convenient as it is what is written on the screen. I guess my patch is a little buggy and would like to improve it

Hi, I'm working on writing a FLAC encoding plugin for a personal cd ripping project of mine which uses paranoia for the raw audio extraction. My basic setup which follows gets me oddly high pitched audio with lots of noise (although the music IS somewhat recognizable). #include <FLAC/stream_encoder.h> FLAC__StreamEncoder *encoder; FILE *output_file_descriptor; encoder =

On UNIX, I am executing an rsync command, from within a script. The command goes something like this: /usr/bin/rsync --verbose --progress --stats --compress --recursive --times --perms --links --safe-links source_dir/ user at target_machine:/parent_path/source_dir In other words, I am replicating source_dir on a remote machine. It ends up next to a lot of sibling, directories, like this: On

At 01:08 PM 6/17/2006, B. Ryan Newberry wrote: >Hi, > >I'm working on writing a FLAC encoding plugin for a personal cd ripping >project of mine which uses paranoia for the raw audio extraction. My >basic setup which follows gets me oddly high pitched audio with lots of >noise (although the music IS somewhat recognizable). > >#include <FLAC/stream_encoder.h> >

Every time ogg123 -bXXX is run, it creates another shared memory segment but fails to destroy it on exit. Thus an increasing number of shm segments keeps piling up and eat all the (often rather limited amount of) available shared memory. The patch below corrects this and also fixes the bizarre abuse of stat() permission bits for shmget(). On systems that support it, I'd very much like to

Greetings one and all; I'm not subscribed to this list so I'm first sending this message to verify that mails from me make it through, and then later I'll send the juicy messages with patches. Also, the address I'm using is IPv6-only and doesn't often work, so drop me from any replies and I'll catch the archives, or drop only the hostname part to get an IPv4 address that

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

Hello, ogg123 | ices2 are doing transcoding but ogg123 is staying frozen under certain circumstances here is the stack #0 0x401f25d4 in __pthread_sigsuspend () from /lib/libpthread.so.0 #1 0xbffff94c in ?? () #2 0x401f2398 in __pthread_wait_for_restart_signal () from /lib/libpthread.so.0 #3 0x401eef0b in pthread_cond_wait@GLIBC_2.0 () from /lib/libpthread.so.0 #4 0x0804b0d3 in

This is a proposed patch to enhance FileSystem.h to add functionality (getting and setting permission bits and mapping an unmapping files). This implementation follows the N3365 proposal regarding permission bits. This functionality is needed for my next patch which will implement llvm/include/Support/FileOutputBuffer.h which is needed by lld. -------------- next part -------------- A

On Fri, May 18, 2012 at 3:07 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > >> +  error_code ec = sys::fs::status(filePathTwine, stat); > > stat is undefined if ec isn't success. ec will be success even in the case of > file_not_found. Actually I was wrong. The Windows and UNIX implementation disagree on this point. I'm going to change it to match

Hi all! I have ''send_status'' table which looks something like these: id code title 1 sent Sent 2 error Sending error 3 success Success Next I would like to associate some processed records with their ''send_status''. Is it better to use: 1) record.status_id = SendStatus.find(:one, :condition => "code=''sent''").id to

Hi, I actually already sent a patch for this: https://patchwork.freedesktop.org/patch/378202/ I'm guessing it hasn't gotten picked up upstream yet? On Mon, 2020-07-27 at 12:00 +0800, Peng Wu wrote: > If CONFIG_DRM_NOUVEAU=y,the following errors > are seen while building crc.h. > > In file included from > /scratch/linux/drivers/gpu/drm/nouveau/nouveau_display.c:47: >

If CONFIG_DRM_NOUVEAU=y,the following errors are seen while building crc.h. In file included from /scratch/linux/drivers/gpu/drm/nouveau/nouveau_display.c:47: /scratch/linux/drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ?nv50_head_crc_late_register?: /scratch/linux/drivers/gpu/drm/nouveau/dispnv50/crc.h:109:47: error: parameter name omitted static inline int

This introduces support for CRC readback on gf119+, using the documentation generously provided to us by Nvidia: https://github.com/NVIDIA/open-gpu-doc/blob/master/Display-CRC/display-crc.txt We expose all available CRC sources. SF, SOR, PIOR, and DAC are exposed through a single set of "outp" sources: outp-active/auto for a CRC of the scanout region, outp-complete for a CRC of both

This introduces support for CRC readback on gf119+, using the documentation generously provided to us by Nvidia: https://github.com/NVIDIA/open-gpu-doc/blob/master/Display-CRC/display-crc.txt We expose all available CRC sources. SF, SOR, PIOR, and DAC are exposed through a single set of "outp" sources: outp-active/auto for a CRC of the scanout region, outp-complete for a CRC of both