similar to: OggPCM format description, rev 3

> Unfortunately the ALSA API defines a number of formats which are > in practice extremely rare. In particular, any unsigned int format > larger than 8 bits. For instance, the only unsigned int type that > libsndfile supports is unsigned 8 bit. I expected this, it just seemed like a good starting point to get more than 7 formats on the table. Specifically I wanted to the logarithmic

Hi John, jkoleszar@on2.com wrote: > Hi all, > > I updated the wiki with another rev of this format. Updates include > support for 43 formats in 14 coding schemes, as derived from the ALSA API. > This seemed like a good way to get a list of what the formats in common > use out there are, so it should be fairly comprehensive. Unfortunately the ALSA API defines a number of

jkoleszar@on2.com wrote: > I updated the wiki with another rev of this format. Updates include > support for 43 formats in 14 coding schemes, as derived from the ALSA API. As an interested bystander, I see that this proposal still has only one format and one rate field for possibly many channels. Earlier someone made the point that you might want to store main and side/back channels

HI all, John Kkoleszar has asked for the option of storing data. He gave the rational that a) SIMD optimized filters b) Writing filter chains. Conrad Parker supported this say that both Core Audio and Jack operate on multiple single channel buffers. On IRC both Jean-Marc and MikeS argued that if OggPCM supports interleaved, the addition of chunked is hard to justify. My slant on the

Michael Smith wrote: >Whilst I accept that there are many good uses for chunked data, I >think the transformation is trivial, particularly given certain >characteristics of the Ogg container. Remember, the data, if you read >an ogg stream into memory, is _already_ likely to be non-contiguous, >due to ogg's structure. It's trivial, and has insignificant additional

Hi Rene, we have discussed the issue of different formats per channel, e.g. different sampling rates. It was not clear whether with PCM sampling of devices this is actually a common (or even used) case. Do you know how multi-channel sound is sampled? Is it created with different widths/rates on different channels? If it is not a common case, we can leave the solution to different streams and

From googling around, it seems that the ogg bitpacker has defined endianness, but I can't find anywhere that says which order it's in. Any help? The endianness of the 24 bit field in the OggPCM header should be specified. I was going to edit the wiki to specify it as network byte order, then realized that you may have standardized on something else in theora/vorbis already.

Michael Smith wrote: > libogg has two bitpackers; a little endian one and a bigendian one. ok, I didn't see it in the docs at http://www.xiph.org/ogg/doc/libogg/reference.html and didn't look in the header file first. My bad. Is it correct to state that the oggpack_* functions use little endian order, and the oggpackB_* functions use big endian order? Is it safe to mix calls to

Rpvs> On 14/07/2020 16:51, Gregory Sloop via samba wrote: >> Yeah, I could setup an extra XCP box - but at smaller setups, it really seems like overkill. >> So, it sounds like restores of the VM work "fine." >> How often do machine accounts reset their passwords? Rpvs> Every 30 days, though this is adjustable, but not recommended >> [This is the one that is

I have OggPCM (as currently defined) support implemented in mencoder and mplayer. I'd like to request that we settle on modifications to this header by the middle of next week or freeze the current header as the official major version 1.0, so I can get the patches cleaned up and released. We will be shipping a separate product based on this work in the near-term future, and compatability

Hi all, Conrad, MikeS, Silvia, Erik, Illi, John and I have been working on another spec. It's definitely not final, but it should address several issues with the previous one. Please comment: http://wiki.xiph.org/index.php/OggPCM2 Two other issues that remained were: 1) Need for minor version (Silvia and I want it, MikeS is against) 2) Having the header 32-bit aligned vs. making the channel

Hi John, all, I still have at least 3 issues: 1) What are we trying to achieve with the "source-ID"? 8 [uint] Source ID (Unique amongst all OggPCM streams in the physical stream) Are we trying to separate the different channels that may be interleaved with each other inside the flat multi-channel sample stream? Interpretation 1: ----------------- So, would each channel be in a

Hi all, The remaining issue to be decided for the OggPCM2 spec is the support of chunked vs interleaved data. Just so that everyone understands what we are talking about, consider a stereo file that gets stored as an OggPCM file. Within an OggPCM packet, the audio samples for the left and right channels can be stored as interleaved where the samples would be: l0, r0, l1, r1, ..... lN, rN

Yeah, I could setup an extra XCP box - but at smaller setups, it really seems like overkill. So, it sounds like restores of the VM work "fine." How often do machine accounts reset their passwords? [This is the one that is most likely to be problematic. Rejoining the domain means a new profile. And that's a big PITA on the client side.] User password changes can simply be handled by

Rpvs> On 14/07/2020 17:25, Gregory Sloop via samba wrote: >> Rpvs> On 14/07/2020 16:51, Gregory Sloop via samba wrote: >>>> Yeah, I could setup an extra XCP box - but at smaller setups, it really seems like overkill. >>>> So, it sounds like restores of the VM work "fine." >>>> How often do machine accounts reset their passwords? >>

I take it you are talking about what is listed under alternative format ? If you have an implementation... you must have a list of enumeration fields... could you put them on the wiki. If we are asking for final comments... the wiki should be tidied up. The original format removed if the general consensus is that this is more on the right track... which it looks to be. Zen. ----- Original

I made a few updates to OggPCM2 http://wiki.xiph.org/index.php/OggPCM2 reflecting the latest discussions. Could everyone have a look at it and see if they agree. Otherwise, what do you feel should be changed? Anyone wants to speak in support of chunked PCM? For all those that are just tired of this mess like me, please express yourself in the new spec I created: OggPCM3

Dear Arc, I feel ashamed of the xiph community. I was always one standing up for the open audio-visual codecs and applications that were developed here and I felt part of that community by contributing. There have been an enormous number of people contributing to xiph specifications and software over the years. Your emails have been an insult to every contributor to xiph that is not in the

I'm using winbind to authenticate telnet session under Red Hat Enterprise 2.1 samba/winbind version 2.2.10 Domains are NT4 domains I have everything set up and configured correctly. Local users and users from trusted domains are able to log-in. I'm having a problem with the resulting username when a user logs on from a trusted domain. Local domain is phonic Trusted domain is thisted

Sampo Syreeni wrote: > Secondly, I'd like to see the channel map fleshed out in more detail. Sampo, I did flesh out the wiki a **little** more. Is the intent clearer now? > (Beware of the pet peeve...) What is that pet peeve? > IMO the mapping should cover at least the > channel assignments possible in WAVE files, the most common Ambisonic > ones, and perhaps some added