similar to: [PATCH] drm/nouveau: Keep RAMIN heap within the channel.

http://bugs.freedesktop.org/show_bug.cgi?id=24662 Summary: [DRM] ramin ioremap fails (no vmalloc space) Product: xorg Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org ReportedBy:

Adapt the NVC0 BAR driver to make it able to support chips that do not expose a BAR3. When this happens, BAR1 is then used for USERD mapping and the BAR alloc() functions is disabled, making GPU objects unable to rely on BAR for data access and falling back to PRAMIN. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c | 115

On Sat, Feb 1, 2014 at 1:16 PM, Alexandre Courbot <acourbot at nvidia.com> wrote: > Adapt the NVC0 BAR driver to make it able to support chips that do not > expose a BAR3. When this happens, BAR1 is then used for USERD mapping > and the BAR alloc() functions is disabled, making GPU objects unable > to rely on BAR for data access and falling back to PRAMIN. > >

The refcount was not protected by the vm lock, fix this.. ------------[ cut here ]------------ WARNING: CPU: 2 PID: 2008 at drivers/gpu/drm/nouveau/core/core/mm.c:242 nouveau_mm_fini+0x4f/0x56 [nouveau]() Modules linked in: adt7475 ebtable_nat ebtables nouveau ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat xt_CHECKSUM iptable_mangle bridge stp llc snd_hda_codec_hdmi kvm_intel ttm kvm

- This is not yet a generic implementation that will work everywhere, but it's a start. - This will fix the corruption surrounding pixmap/texture bo moves on nv50. Signed-off-by: Maarten Maathuis <madman2003 at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_bo.c | 8 ++- drivers/gpu/drm/nouveau/nouveau_channel.c | 9 ++- drivers/gpu/drm/nouveau/nouveau_dma.c | 26

http://bugs.freedesktop.org/show_bug.cgi?id=15736 Summary: Account request Product: xorg Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org ReportedBy: younes.m at

Yes, I have made that search, but I'm restricted to Java. On 11/01/2010 12:21 PM, Steve Kann wrote: > Have you tried typing "speex rtp" into google code search? It gives lots > of examples of real applications which do exactly that. > > http://www.google.com/codesearch?as_q=speex+rtp > > > -SteveK > > > On 11/1/10 1:13 PM, "Jeff

Some firmware images may be large (64K), so using kmalloc memory is inappropriate for them. Use vmalloc instead, to avoid high-order allocation failures. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: stable at vger.kernel.org --- Couldn't get video decoding started on a long-running system due to high-order allocation failures. This seems like a fine use-case for vmalloc.

Have you tried typing "speex rtp" into google code search? It gives lots of examples of real applications which do exactly that. http://www.google.com/codesearch?as_q=speex+rtp -SteveK On 11/1/10 1:13 PM, "Jeff Ramin" <jeff.ramin at singlewire.com> wrote: > >Thanks again Steve. I'll search for the term you mention below. > >What I really want is to

Thanks again Steve. I'll search for the term you mention below. What I really want is to take the output of the speex encoder and spit it out on the network via RTP. I haven't been able to find a library or code example that does that. On 11/01/2010 12:03 PM, Steve Kann wrote: > Jeff, > > It's in the manual: > >

Thanks for the help folks, but I got this working a couple hours ago. =) I'm quite please after struggling with it for a few days. I just needed to take each audio tag from the FLV file and feed the contents of the tag (except for the first byte) to the jspeex decoder and write the results to a file. Jozsef - it is possible to specify 8KHz in the flash client and decode it as such. Speex

Jeff, It's in the manual: http://www.speex.org/docs/manual/speex-manual/node10.html (table 3 and 4). However, if you're asking this, you're probably trying to do something wrong, or the hard way. You probably shouldn't be taking speex output, and trying to "count bytes". If you are using the API, then you will just get the bits out, and then you'll know how

On Mon, Jun 3, 2013 at 5:02 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > These chipsets include the VP2 engine which is composed of a bitstream > processor (BSP) that decodes H.264 and a video processor (VP) which can > do iDCT/mo-comp/etc for MPEG1/2, H.264, and VC-1. Both of these are > driven by separate xtensa chips embedded in the hardware. This patch > provides the

The link is http://www.adobe.com/devnet/rtmp/. TC Message stands for TinCan message. It is 11 bytes long, first byte is message type, three bytes of payload length four bytes of timestamp and three bytes of stream ID. The first byte of the payload for audio message is the format byte and the rest of the byte is the payload. Jozsef ----- Original Message ---- From: Jeff Ramin <jeff.ramin

Thanks Steve. Is there a document anywhere that shows how many bytes/bits of data are produced by the speex encoding process for a given amount of time sampling rate and quality setting? On 11/01/2010 09:41 AM, Steve Kann wrote: > Jeff, > > RFC-5574 is standards-track: http://tools.ietf.org/html/rfc5574 so, > while it's not an approved standard, it's more standardized

It removes a hack from nouveau code which had to detect which region to pass to kick vesafb/efifb. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> Cc: Eric Anholt <eric at anholt.net> Cc: Ben Skeggs <bskeggs at redhat.com> Cc: Thomas Hellstrom <thellstrom at vmware.com> Cc: Dave Airlie <airlied at redhat.com> Cc: Peter Jones <pjones at redhat.com>

Jeff, RFC-5574 is standards-track: http://tools.ietf.org/html/rfc5574 so, while it's not an approved standard, it's more standardized than a lot of interoperable traffic on the internets these days. The RFC specifies packetization guidelines, which is basically that you put one or more frames in a packet, and then pad the rest with 0 bits until you have a while number of octets.

Is there a document somewhere that describes speex-encoded FLV files? What is a TC message? Thanks. Jozsef Vass wrote: > FLV contains TC messages? TC message payload contains a format byte and speex frames (up to eight). In the format byte 0xb0 indicates speex. Speex is always 16 kHz, 16 bit, mono. > > Jozsef > > > Message: 1 > Date: Mon, 16 Nov 2009 14:40:20 -0600 >

Is Jspeex still being worked on? Is there somewhere I can send the code changes I've made to facilitate smooth streaming? On 11/09/2010 11:33 AM, Jeff Ramin wrote: > > Just an update, and a follow-up question: > > I'm making progress on this issue, and will likely have something working > very soon, now that I understand how the jspeex transcoding classes work. >

It simplifies nouveau code by removal of detection which region to pass to kick vesafb/efifb. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> Cc: Eric Anholt <eric at anholt.net> Cc: Ben Skeggs <bskeggs at redhat.com> Cc: Thomas Hellstrom <thellstrom at vmware.com> Cc: Dave Airlie <airlied at redhat.com> Cc: Peter Jones <pjones at redhat.com> Cc: