search for: 68kb

Hi evryone ) My name is Vasily. I am a software developer from Ukrane, and i am going to use Speex on TMS320F28335 DSP-controller wich has only 68KB of RAM. And I worry about this. I can't find memory requirements in speex manual(only some about optimization). Can anyone tell me, how many RAM Speex can eat at 8kbs realtime encoding and decoding with echo canceller and jitter buffer enabled? P.S. I found some about echo canceller, but noth...

Jean-Marc Valin escreveu: >> My name is Vasily. >> I am a software developer from Ukrane, and i am going to use Speex on >> TMS320F28335 DSP-controller wich has only 68KB of RAM. > > Assuming you've got ROM to hold the code/constants and that RAM is only > used for variables, then 68 kB should probably be enough. I am concerned if the TMS320F28335 as a whole can handle speex: 16 bits, 150MHz, dual MAC, floating point 512kbytes Flash, 68kbytes RAM, wit...

...tries to do this, but it'd be silly to duplicate in every mkfs. Well, blkid already has a way to _detect_ a lot of filesystem signatures, so it might be relatively easy to exploit the type_array[] entries to have it zap out all of these blocks. That said, the majority of them are in the first 68kB of the filesystem (mdraid excluded) so it shouldn't be too hard to zero them out. Let's hope nobody ever uses "0x00000000" as magic. mke2fs already tries to do this, though I notice: - the zap_sector() call will skip the entire write if there is a BSD bootblock, instead of ski...

...: Thursday, March 27, 2008 11:10 AM Subject: Re: [Speex-dev] How many RAM Speex need?? > > > Jean-Marc Valin escreveu: >>> My name is Vasily. >>> I am a software developer from Ukrane, and i am going to use Speex on >>> TMS320F28335 DSP-controller wich has only 68KB of RAM. >> >> Assuming you've got ROM to hold the code/constants and that RAM is only >> used for variables, then 68 kB should probably be enough. > > I am concerned if the TMS320F28335 as a whole can handle speex: > 16 bits, 150MHz, dual MAC, floating point > 512k...

...9 DoyleBrunson kernel: Free pages: 63200kB (55988kB HighMem) Jan 23 12:52:19 DoyleBrunson kernel: Active:352452 inactive:210731 dirty:0 writeback:11 unstable:0 free:15800 slab:207608 mapped-file:8236 mapped-anon:538350 pagetables:249759 Jan 23 12:52:19 DoyleBrunson kernel: DMA free:3588kB min:68kB low:84kB high:100kB active:0kB inactive:0kB present:16384kB pages_scanned:0 all_unreclaimable? yes Jan 23 12:52:19 DoyleBrunson kernel: lowmem_reserve[]: 0 0 880 4272 Jan 23 12:52:19 DoyleBrunson kernel: DMA32 free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0 all...

...===== snip... Jul 30 16:26:21 srv1 kernel: Free pages: 12044kB (124kB HighMem) Jul 30 16:26:21 srv1 kernel: Active:119791 inactive:120544 dirty:0 writeback:12 unstable:0 free:3011 slab:7550 mapped-file:1746 mapped-anon:215165 pagetabl es:3364 Jul 30 16:26:32 srv1 kernel: DMA free:4096kB min:68kB low:84kB high:100kB active:3948kB inactive:3608kB present:16384kB pages_scanned:17135 all_unreclaimab le? yes Jul 30 16:26:32 srv1 kernel: lowmem_reserve[]: 0 0 880 1007 Jul 30 16:26:33 srv1 kernel: DMA32 free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unre...

...3 isolated_anon:3424 active_file:130 inactive_file:284 isolated_file:160 unevictable:0 dirty:0 writeback:245 unstable:0 free:14234 slab_reclaimable:2891 slab_unreclaimable:13218 mapped:239 shmem:14 pagetables:28858 bounce:0 Node 0 DMA free:8252kB min:340kB low:424kB high:508kB active_anon:2168kB inactive_anon:4624kB active_file:4kB inactive_file:144kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15348kB mlocked:0kB dirty:0kB writeback:28kB mapped:8kB shmem:0kB slab_reclaimable:12kB slab_unreclaimable:128kB kernel_stack:8kB pagetables:376kB unstable:0kB bounce:0kB writ...

...cold: high 62, batch 15 used:10 Apr 17 07:49:11 mail2 kernel: Free pages: 2871096kB (2863824kB HighMem) Apr 17 07:49:11 mail2 kernel: Active:90263 inactive:9647 dirty:30 writeback:0 unstable:0 free:717774 slab:215197 mapped:2666 pagetables:1253 Apr 17 07:49:11 mail2 kernel: DMA free:3588kB min:68kB low:84kB high:100kB active:0kB inactive:0kB present:16384kB pages_scanned:0 all_unreclaimable? yes Apr 17 07:49:11 mail2 kernel: lowmem_reserve[]: 0 0 880 4848 Apr 17 07:49:11 mail2 kernel: DMA32 free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaima...

...aimable? yes lowmem_reserve[]: 0 3235 7959 7959 DMA32 free:29480kB min:4636kB low:5792kB high:6952kB active_anon:510136kB inactive_anon:40212kB active_file:1038872kB inactive_file:1060372kB unevictable:32kB isolated(anon):0kB isolated(file):0kB present:3390912kB managed:3314444kB mlocked:32kB dirty:68kB writeback:0kB mapped:171940kB shmem:55828kB slab_reclaimable:589856kB slab_unreclaimable:18792kB kernel_stack:3008kB pagetables:12812kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 4723 4723 Normal free...

...ct vmci_datagram_queue_entry, + listItem); + ASSERT(nextEntry && nextEntry->dg); + + /* + * The following size_t -> int truncation is fine as + * the maximum size of a (routable) datagram is 68KB. + */ + rv = (int)nextEntry->dgSize; + } + spin_unlock(&context->lock); + + /* Caller must free datagram. */ + ASSERT(dqEntry->dgSize == VMCI_DG_SIZE(dqEntry->dg)); + *dg = dqEntry->dg; + dqEntry->dg = NULL; +...

...ct vmci_datagram_queue_entry, + listItem); + ASSERT(nextEntry && nextEntry->dg); + + /* + * The following size_t -> int truncation is fine as + * the maximum size of a (routable) datagram is 68KB. + */ + rv = (int)nextEntry->dgSize; + } + spin_unlock(&context->lock); + + /* Caller must free datagram. */ + ASSERT(dqEntry->dgSize == VMCI_DG_SIZE(dqEntry->dg)); + *dg = dqEntry->dg; + dqEntry->dg = NULL; +...

* * * This series of VMCI linux upstreaming patches include latest udpate from VMware to address Greg's and all other's code review comments. Summary of changes: - Rebase our linux kernel tree from v3.5 to v3.7. - Fix all checkpatch warnings and errors. Fix some checkpatch with -strict errors. This addresses Greg's comment: On 15 Nov 2012

* * * This series of VMCI linux upstreaming patches include latest udpate from VMware to address Greg's and all other's code review comments. Summary of changes: - Rebase our linux kernel tree from v3.5 to v3.7. - Fix all checkpatch warnings and errors. Fix some checkpatch with -strict errors. This addresses Greg's comment: On 15 Nov 2012

* * * In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the Virtual Machine Communication Interface (vmw_vmci) and VMCI Sockets (vmw_vsock) kernel modules for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vmw_vmci kernel module. The vmw_vsock kernel module will be presented in a later

* * * In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the Virtual Machine Communication Interface (vmw_vmci) and VMCI Sockets (vmw_vsock) kernel modules for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vmw_vmci kernel module. The vmw_vsock kernel module will be presented in a later

Second revision of the VMware VMCI RFC patchset. It incorperates fixes for all the feedback about the comment blocks and style and now passes checkpatch with 0 errors and 0 warnings. Thanks to all who have reviewed the code thus far. * * * In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the Virtual Machine Communication

Second revision of the VMware VMCI RFC patchset. It incorperates fixes for all the feedback about the comment blocks and style and now passes checkpatch with 0 errors and 0 warnings. Thanks to all who have reviewed the code thus far. * * * In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the Virtual Machine Communication

In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the Virtual Machine Communication Interface (vmw_vmci) and VMCI Sockets (vmw_vsock) kernel modules for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vmw_vmci kernel module. The vmw_vsock kernel module will be presented in a later post.

In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the Virtual Machine Communication Interface (vmw_vmci) and VMCI Sockets (vmw_vsock) kernel modules for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vmw_vmci kernel module. The vmw_vsock kernel module will be presented in a later post.

In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the Virtual Machine Communication Interface (vmw_vmci) and VMCI Sockets (vmw_vsock) kernel modules for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vmw_vmci kernel module. The vmw_vsock kernel module will be presented in a later post.