Apple iPad en uygun fiyatlarla enucuzsite.com'da
Bu e-postayD1 gC6rCntClerken sorun mu yaE adD1nD1z? Birde bu versiyonu deneyin. [IMAGE] tech@openbsd.org adresiniz e-bCltenimize kayD1tlD1dD1r. KoE ullar | GCvenlik | Listeden CD1kmak D0stiyorum Copyright 2011 Enucuzsite. All rights reserved. Enucuzsite Web: www.enucuzsite.com [IMAGE]
Re: aucat(1) block sizes
On Fri, Jun 03, 2011 at 02:10:37PM +0300, Alexey Suslikov wrote: Hello tech@. aucat(1) manual says: Streams created with the -t option export the server clock using MTC, allowing non-audio software or hardware to be synchronized to the audio stream. The following sample rates (-r) and block sizes (-z) are recommended for maximum accuracy: o 44100Hz, 441 frames o 48000Hz, 400 frames o 48000Hz, 480 frames o 48000Hz, 500 frames For me, it was unclear why manual suggests different block sizes for one frequency until I understood MTC resolution being 96, 100 or 120 which is described much earlier in the manual. This is because I expected a bit self-explanatory text here so I can think aha, I saw these numbers earlier or ok, let's search why these are 96, 100 and 120. Something like o 44100Hz, 441 frames (MTC resolution is 100) o 48000Hz, 400 frames (MTC resolution is 120) o 48000Hz, 480 frames (MTC resolution is 100) o 48000Hz, 500 frames (MTC resolution is 96) ok, what about the diff below? Moreover, above explanation of MTC and examples are somewhat duplicate/overlap earlier -z description: -z nframes The audio device block size in frames. This is the number of frames between audio clock ticks, i.e. the clock resolution. If a stream is created with the -t option, and MTC is used for synchronization, the clock resolution must be 96, 100 or 120 ticks per second for maximum accuracy. For instance, 120 ticks per second at 48000Hz corresponds to a 400 frame block size. Is there any better way to explain this? With current text I forced to jump up and down to understand what is what. I don't know, I take any ideas diffs. Currently, we try to keep the DESCRIPTION section complete and self-consistent. Other sections are to give advices, and/or explain a little bit more how aucat works. If you don't use mtc (or you already know how mtc works), you don't need to read other sections and so no need to jump up and down. IMHO we need a section (or separate man page) about audio and midi concepts and about how aucat works. -- Alexandre Index: aucat.1 === RCS file: /home/alex/sndio/cvs/sndio/aucat/aucat.1,v retrieving revision 1.16 diff -u -p -r1.16 aucat.1 --- aucat.1 3 Jun 2011 09:07:16 - 1.16 +++ aucat.1 3 Jun 2011 14:14:36 - @@ -517,21 +517,23 @@ Streams created with the .Fl t option export the server clock using MTC, allowing non-audio software or hardware to be synchronized to the audio stream. +Maximum accuracy is achieved when the number of blocks per +second is equal to one of the standard MTC clock rates (96, 100 and 120Hz). The following sample rates .Pq Fl r and block sizes .Pq Fl z -are recommended for maximum accuracy: +are recommended: .Pp .Bl -bullet -offset indent -compact .It -44100Hz, 441 frames +44100Hz, 441 frames (MTC rate is 100Hz) .It -48000Hz, 400 frames +48000Hz, 400 frames (MTC rate is 120Hz) .It -48000Hz, 480 frames +48000Hz, 480 frames (MTC rate is 100Hz) .It -48000Hz, 500 frames +48000Hz, 500 frames (MTC rate is 96Hz) .El .Pp For instance, the following command will create two devices:
Re: aucat(1) block sizes
On Fri, Jun 3, 2011 at 17:45, Alexandre Ratchov a...@caoua.org wrote: On Fri, Jun 03, 2011 at 02:10:37PM +0300, Alexey Suslikov wrote: Hello tech@. aucat(1) manual says: Streams created with the -t option export the server clock using MTC, allowing non-audio software or hardware to be synchronized to the audio stream. The following sample rates (-r) and block sizes (-z) are recommended for maximum accuracy: o 44100Hz, 441 frames o 48000Hz, 400 frames o 48000Hz, 480 frames o 48000Hz, 500 frames For me, it was unclear why manual suggests different block sizes for one frequency until I understood MTC resolution being 96, 100 or 120 which is described much earlier in the manual. This is because I expected a bit self-explanatory text here so I can think aha, I saw these numbers earlier or ok, let's search why these are 96, 100 and 120. Something like o 44100Hz, 441 frames (MTC resolution is 100) o 48000Hz, 400 frames (MTC resolution is 120) o 48000Hz, 480 frames (MTC resolution is 100) o 48000Hz, 500 frames (MTC resolution is 96) ok, what about the diff below? For me, it's clearer. You use Hz across diff, but -z description tells about ticks per second. Is that on purpose? Moreover, above explanation of MTC and examples are somewhat duplicate/overlap earlier -z description: -z nframes The audio device block size in frames. This is the number of frames between audio clock ticks, i.e. the clock resolution. If a stream is created with the -t option, and MTC is used for synchronization, the clock resolution must be 96, 100 or 120 ticks per second for maximum accuracy. For instance, 120 ticks per second at 48000Hz corresponds to a 400 frame block size. Is there any better way to explain this? With current text I forced to jump up and down to understand what is what. I don't know, I take any ideas diffs. Currently, we try to keep the DESCRIPTION section complete and self-consistent. Other sections are to give advices, and/or explain a little bit more how aucat works. If you don't use mtc (or you already know how mtc works), you don't need to read other sections and so no need to jump up and down. IMHO we need a section (or separate man page) about audio and midi concepts and about how aucat works. -- Alexandre Index: aucat.1 === RCS file: /home/alex/sndio/cvs/sndio/aucat/aucat.1,v retrieving revision 1.16 diff -u -p -r1.16 aucat.1 --- aucat.1 3 Jun 2011 09:07:16 - 1.16 +++ aucat.1 3 Jun 2011 14:14:36 - @@ -517,21 +517,23 @@ Streams created with the .Fl t option export the server clock using MTC, allowing non-audio software or hardware to be synchronized to the audio stream. +Maximum accuracy is achieved when the number of blocks per +second is equal to one of the standard MTC clock rates (96, 100 and 120Hz). The following sample rates .Pq Fl r and block sizes .Pq Fl z -are recommended for maximum accuracy: +are recommended: .Pp .Bl -bullet -offset indent -compact .It -44100Hz, 441 frames +44100Hz, 441 frames (MTC rate is 100Hz) .It -48000Hz, 400 frames +48000Hz, 400 frames (MTC rate is 120Hz) .It -48000Hz, 480 frames +48000Hz, 480 frames (MTC rate is 100Hz) .It -48000Hz, 500 frames +48000Hz, 500 frames (MTC rate is 96Hz) .El .Pp For instance, the following command will create two devices:
Re: aucat(1) block sizes
On Fri, Jun 03, 2011 at 06:03:32PM +0300, Alexey Suslikov wrote: On Fri, Jun 3, 2011 at 17:45, Alexandre Ratchov a...@caoua.org wrote: On Fri, Jun 03, 2011 at 02:10:37PM +0300, Alexey Suslikov wrote: Hello tech@. aucat(1) manual says: Streams created with the -t option export the server clock using MTC, allowing non-audio software or hardware to be synchronized to the audio stream. The following sample rates (-r) and block sizes (-z) are recommended for maximum accuracy: o 44100Hz, 441 frames o 48000Hz, 400 frames o 48000Hz, 480 frames o 48000Hz, 500 frames For me, it was unclear why manual suggests different block sizes for one frequency until I understood MTC resolution being 96, 100 or 120 which is described much earlier in the manual. This is because I expected a bit self-explanatory text here so I can think aha, I saw these numbers earlier or ok, let's search why these are 96, 100 and 120. Something like o 44100Hz, 441 frames (MTC resolution is 100) o 48000Hz, 400 frames (MTC resolution is 120) o 48000Hz, 480 frames (MTC resolution is 100) o 48000Hz, 500 frames (MTC resolution is 96) ok, what about the diff below? For me, it's clearer. You use Hz across diff, but -z description tells about ticks per second. Is that on purpose? both are the same, Hz is shorter. It's similar to the sample rate, frames per secord or Hz. -- Alexandre
msk support for Yukon 88E8040
Hi,
I apologize if this list is not appropriate for this request.
I am trying to add support for Marvell Yukon FE+ network card under
NetBSD according to http://gnats.netbsd.org/42417. The chip of this card
(Yukon 88E8040) runs with msk driver. Under NetBSD, the driver derives
from the OpenBSD one. But OpenBSD runs 88E8040 while NetBSD not. I have
begun to port code from OpenBSD to NetBSD, but it doesn't work yet. I
have looked into FreeBSD and Linux drivers too. FreeBSD has these pieces
of code:
if (sc-msk_hw_rev == CHIP_REV_YU_FE_P_A0) {
/*
* XXX
* FE+ A0 has status LE writeback bug so msk(4)
* does not rely on status word of received frame
* in msk_rxeof() which in turn disables all
* hardware assistance bits reported by the status
* word as well as validity of the received frame.
* Just pass received frames to upper stack with
* minimal test and let upper stack handle them.
*/
sc-msk_pflags |= MSK_FLAG_NOHWVLAN |
MSK_FLAG_NORXCHK | MSK_FLAG_NORX_CSUM;
}
[...]
/* Another magic for Yukon FE+ - From Linux. */
if (sc-msk_hw_id == CHIP_ID_YUKON_FE_P
sc-msk_hw_rev == CHIP_REV_YU_FE_P_A0)
reg = 0x178;
CSR_WRITE_2(sc, MR_ADDR(sc_if-msk_port, RX_GMF_FL_THR), reg);
I don't understand how OpenBSD manages to run this card without these
*hacks*. Surely OpenBSD is very well written ! My current patch adds the
conditional blocks corresponding to my card from OpenBSD if_msk.c to the
NetBSD one (but it's not enough). Anybody knows the magic behavior of
this driver ?
Thank you,
Fred
--
FrC)dC)ric Fauberteau
Re: iwn(4) MSI
On Thu, Jun 02, 2011 at 10:49:43PM +0100, Owain Ainsworth wrote:
:Been running with this for a couple of weeks, seems to work fine.
:
:ok?
:
:diff --git dev/pci/if_iwn.c dev/pci/if_iwn.c
:index 16765f4..a54556b 100644
:--- dev/pci/if_iwn.c
:+++ dev/pci/if_iwn.c
:@@ -338,7 +338,8 @@ iwn_attach(struct device *parent, struct device *self,
void *aux)
: }
:
: /* Install interrupt handler. */
:- if (pci_intr_map(pa, ih) != 0) {
:+ if (pci_intr_map_msi(pa, ih) != 0
:+ pci_intr_map(pa, ih) != 0) {
: printf(: can't map interrupt\n);
: return;
: }
:
:--
:The idea is to die young as late as possible.
: -- Ashley Montague
:
Works for me for past week or so.
=]
thank me now. =p www.bigmoneymadesimple.com blessing mj
