search for: resynchronised

From: Steve Underwood <steveu at coppice.org> > It seems some cards use a PLL for their ADC, so they can lock to an > incoming SPDIF signal, but always use a local crystal clock source for > their DAC. These cards do not have their ADC and DAC synchronised. Do common on-board or PCI sound card lock to some incoming signal? Yes, there is a crystal oscillator and a PLL or divider to

Hi all, The conclusion of the discussion is that most sound cards indeed have different capture and playing frequencies for the unknown reasons. But we all know the adaptive filter of the AEC relies on the synchronization of the far-end and near-end sampling rates. Then Has anybody tried to use speex AEC in Windows system? How do you solve this problem? (I have tested speex AEC. In most

AFAICT our current version does not correspond to any version in the Linux history. This commit resynchronised to the state in Linux commit 598bae70c2a8e35c8d39b610cca2b32afcf047af. Differences from upstream: find_cpio_data is __init, printk instead of pr_*. This appears to fix Debian bug #785187. "Appears" because my test box happens to be AMD and the issue is that the (valid) cpio generated by...

>>> On 01.07.15 at 16:43, <ian.campbell at citrix.com> wrote: > AFAICT our current version does not correspond to any version in the > Linux history. This commit resynchronised to the state in Linux > commit 598bae70c2a8e35c8d39b610cca2b32afcf047af. > > Differences from upstream: find_cpio_data is __init, printk instead of > pr_*. > > This appears to fix Debian bug #785187. "Appears" because my test box > happens to be AMD and the issue is...

On Wed, 2017-05-24 at 13:53 +0000, Chris Olson wrote: > One of our STEM interns recently observed that there are > inexpensive clocks that sync via radio to standard time > services.? This begged a question about why every computer > would not have a radio module to receive time.? Our senior > staff did not have a good answer or if time from such a > radio module would be

Hi, I''am trying to use DRBD with XEN 3.0, the xen kernel is an 2.6.12.6 and i am using DRBD 0.7.14. The primary node is an opensuse 10 linux (not virtualized). The 2 volumes are LVM logical volumes with internal metadatas, there size is 54G. The secondary node is an opensuse 10 also but running over xen domain-0. When i setup drbd, synchronisation starts, but the whole system just

I have a (CentOS4.5) cluster in which the servers mount a GFS partition which is an LVM2 logical volume created as a mirror of two iSCSI- connected drives (with a third for the log). The LV was created using a command along the lines of: lvcreate -m 1 ... /dev/sdb /dev/sdc /dev/sdd where sd[bc] are the mirrored (iSCSI) PVs in the VG and sdd is the log. I have this working and can write data

Hi John, I'm forwarding this email to the relevant developer lists at Xiph.Org, where the format was created and where the experts gather. I'm certain there is a design reason for putting the bos pages of all logical bitstreams together at the start. My guess is that with digital media you usually have a delay time for setting up the decoders for a specific format and by clustering

Hi John, I'm forwarding this email to the relevant developer lists at Xiph.Org, where the format was created and where the experts gather. I'm certain there is a design reason for putting the bos pages of all logical bitstreams together at the start. My guess is that with digital media you usually have a delay time for setting up the decoders for a specific format and by clustering

One of our STEM interns recently observed that there are inexpensive clocks that sync via radio to standard time services.? This begged a question about why every computer would not have a radio module to receive time.? Our senior staff did not have a good answer or if time from such a radio module would be supported by the operating system. When I was a student, such questions would have earned

Windoze in da NUT house! Codebase of the NUT for Windows branch was merged to main codebase, not in the least to avoid bit-rot and need for resynchronisation with merge conflicts that regularly arose as the two branches "just co-existed". More community work is needed to complete some drivers' functionality and MSI package delivery, but for many use-cases it may already "just

Windoze in da NUT house! Codebase of the NUT for Windows branch was merged to main codebase, not in the least to avoid bit-rot and need for resynchronisation with merge conflicts that regularly arose as the two branches "just co-existed". More community work is needed to complete some drivers' functionality and MSI package delivery, but for many use-cases it may already "just

On Tue, 2015-05-19 at 13:31 +0200, Stephan Seitz wrote: > On Fri, May 15, 2015 at 08:26:42AM +0100, Ian Campbell wrote: > >Here's an idea. First extract the real initrd from the back half of the > >initrd: > > ijc at dagon:tmp$ cat /boot/initrd.img | ( cpio -t >&2 ; cat ) > initrd.real > > kernel > > kernel/x86 > >

Then why ONE sound card have different capture and playback rate? It must be ONE single physical clock generator which is used by both ADC and DAC in the sound card, isn't it? If you are a hardware engineer. Will you design two different physical clock for ADC and DAC seperately? What on earth causes this problem? Who knows its intrinsic real reason? Isn't there any other solutions? For

"Good news, everyone!" With CI builds of the branch now regularly passing on both the multiplatform FOSS NUT CI farm (including linux+mingw cross-builds), and CircleCI with MacOS, and newly on AppVeyor with Windows+MSYS2 (including integration tests with live upsd and some dummy-ups instances), after ironing a few wrinkles I intend to PR and merge it into the main NUT codebase soon,

"Good news, everyone!" With CI builds of the branch now regularly passing on both the multiplatform FOSS NUT CI farm (including linux+mingw cross-builds), and CircleCI with MacOS, and newly on AppVeyor with Windows+MSYS2 (including integration tests with live upsd and some dummy-ups instances), after ironing a few wrinkles I intend to PR and merge it into the main NUT codebase soon,

Back from vacations, and before I dive into real-life work, I went over some ideas and notes from the NUT for Windows effort. Now they should be tracked at https://github.com/orgs/networkupstools/projects/2/views/1 and community help is welcome :) I probably forgot or missed some caveats - so feel free to post issues for this project if you think of some more... Jim On Thu, Jun 23, 2022, 23:52

Back from vacations, and before I dive into real-life work, I went over some ideas and notes from the NUT for Windows effort. Now they should be tracked at https://github.com/orgs/networkupstools/projects/2/views/1 and community help is welcome :) I probably forgot or missed some caveats - so feel free to post issues for this project if you think of some more... Jim On Thu, Jun 23, 2022, 23:52

Hi, I'm using Gluster 3.3.0-1.el6.x86_64, on two storage nodes, replicated mode (fs1, fs2) Node specs: CentOS 6.2 Intel Quad Core 2.8Ghz, 4Gb ram, 3ware raid, 2x500GB sata 7200rpm (RAID1 for os), 6x1TB sata 7200rpm (RAID10 for /data), 1Gbit network I've it mounted data partition to web1 a Dual Quad 2.8Ghz, 8Gb ram, using glusterfs. (also tried NFS -> Gluster mount) We have 50Gb of

Hi all, just letting you know that I am about to submit the final version of the Ogg 1.0 file format Internet-Draft to the IETF. It is due by today (March 3, Monday - Internet Draft final submission cut-off at 09:00 ET) for the next IETF meeting and I expect they will promote it to RFC status at the meeting. Please send any last-minute changes to me. Cheers, Silvia. <p><p>